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(54) INFORMATION PROCESSING APPARATUS 

(57) A license server offering a content decryption 
key assigns leaves of a key-managed hierarchical tree 
structure to clients, and generates a set of node keys as 
a device node key for transmission to each client togeth- 
er with a leaf ID and a private key of the client in ques- 
tion. When an intermediate node of the tree structure is 
deemed to be the top, all nodes subordinate to the top 
are established as nodes related to a category defined 



for the top node. In this setup, a manufacturer, a content 
provider, or like entity managing the top node assigned 
the category generates uniquely an enabling key block 
that defines the node in question as the top, and distrib- 
utes the enabling key block to devices belonging to 
nodes subordinate to the top node. The scheme allows 
the managing entity to renew the key without affecting 
devices belonging to any other category. 
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Description 
TECHNICAL FIELD 

[0001] The present invention relates to an information 
processing apparatus. More particularly, the invention 
relates to an information processing apparatus for al- 
lowing a single device to manage contents belonging to 
different categories. 

TECHNICAL FIELD 

[0002] With the Internet coming into general use to- 
day, a number of schemes.have been proposed where- 
by audio and video contents are distributed over the In- 
ternet for use with devices. Some of these schemes 
have now been implemented. In such cases, contents 
are subject to diverse use conditions to protect their cop- 
yright. Each device handling contents can make use of 
them only if it satisfies specific use conditions applicable 
to these contents. 

[0003] Conventionally, the devices dealing with con- 
tents had to manage all contents in all categories in the 
same manner. That is, each device could not change 
the manner of managing contents depending on the dif- 
ferent categories of the services offered, use conditions 
applied, or content providers involved. This posed prob- 
lems for both content providers and device users- the 
content providers were unable flexibly to manage the 
contents they provided, and device users found it diffi- 
cult to operate their devices in utilizing the contents. 

DISCLOSURE OF INVENTION 

[0004] The present invention has been made in view 
of the above circumstances and provides an apparatus, 
a method and a program for allowing a single device to 
make use of a plurality of contents belonging to different 
categories of services offered, use conditions applied 
and content providers involved, thereby affording con- 
venience to both the content providers and device users 
and improving the operability of the devices employed. 
[0005] In carrying out the invention and according to 
a first aspect thereof, there is provided an information 
processing apparatus comprising: an assigning element 
which, in a key-managed hierarchical tree structure hav- 
ing a content provision category assigned to a first node 
on a given level of the structure, assigns uniquely a sec- 
ond information processing apparatus to a leaf subordi- 
nate to the first node; and a providing element for pro- 
viding the second information processing apparatus 
with the device node key corresponding to a path be- 
tween the leaf assigned by the assigning element and 
the first node. 

[0006] In a preferred structure according to the first 
aspect of the invention, the providing element may fur- 
ther provide the second information processing appara- 
tus with leaf identification information for identifying the 



leaf, in addition to the device node key. 
[0007] In another preferred structure according to the 
first aspect of the invention, the information processing 
apparatus may further comprise a receiving element for 
5 receiving from the second information processing appa- 
ratus a license request including both the leaf identifica- 
tion information and license identification information for 
identifying a license granting the use of the content; and 
a transmitting element for transmitting the license which 
" is added the leaf identification information included in 
the license request and which comprises a digital sig- 
nature. * 

[0008] In a further preferred structure according to the 
first aspect of the invention, the providing element may 
15 further provide the second information processing ap- 
paratus with a private key and a public key of the second 
information processing apparatus as well as a public key 
of the information processing apparatus, in addition to 
the device node key. 

20 [0009] According to a second aspect of the invention 
there is provided an information processing method for 
use with an information processing apparatus for pro- 
viding a device node key used to decrypt an enabling 
key block included in a content, the information process- 
es mg method comprising the steps of: in a key-managed 
hierarchical tree structure having a content provision 
category assigned to a first node on a given level of the 
structure, assigning uniquely a second information 
processing apparatus to a leaf subordinate to the first 
so node; and providing the second information processing 
apparatus with the device node key corresponding to a 
path between the leaf assigned in the assigning step 
and the first node. 

[0010] According to a third aspect of the invention, 
35 there is provided a storage medium which stores a com- 
puter-readable program for use with an information 
processing apparatus for providing a device node key 
used to decrypt an enabling key block included in a con- 
tent, the program comprising the steps of: in a key-man- 
40 aged hierarchical tree structure having a content provi- 
sion category assigned to a first node on a given level 
of the structure, assigning uniquely a second informa- 
tion processing apparatus to a leaf subordinate to the 
first node; and providing the second information 
<5 processing apparatus with the device node key corre- 
sponding to a path between the leaf assigned in the as- 
signing step and the first node. 
[001 1] According to a fourth aspect of the invention 
there is provided a program executable by a computer 
50 for controlling an information processing apparatus for 
providing a device node key used to decrypt an enabling 
key block included in a content, the program causing the 
computer to carry out the steps of: in a key-managed 
hierarchical tree structure having a content provision 
55 category assigned to a first node on a given level of the 
structure, assigning uniquely a second information 
processing apparatus to a leaf subordinate to the first 
node; and providing the second information processing 
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apparatus with the device node key corresponding to a 
path between the leaf assigned in the assigning step 
and the first node. 

[0012] According to a fifth aspect of the invention, 
there is provided an information processing apparatus 
for providing a license granting the use of a content, the 
information processing apparatus comprising: a receiv- 
ing element for receiving from a second information 
processing apparatus leaf identification information for 
identifying in a key-managed hierarchical tree structure 
a leaf assigned to the second information processing 
apparatus; and a transmitting element which, if the leaf 
identification information received by the receiving ele- 
ment identifies a leaf subordinate to a first node on a 
given level of the structure, the first node being assigned 
a content provision category, then transmits the license 
including the leaf identification information to the second 
information processing apparatus. 
[0013] According to a sixth aspect of the invention, 
there is provided an information processing method for 
use with an information processing apparatus for pro- 
viding a license granting the use of a content, the infor- 
mation processing method comprising the steps of: re- 
ceiving from a second information processing apparatus 
leaf identification information for identifying in a key- 
managed hierarchical tree structure a leaf assigned to 
the second information processing apparatus; and if the 
leaf identification information received in the receiving 
step identifies a leaf subordinate to a first node on a giv- 
en level of the structure, the first node being assigned 
a content provision category, then transmitting the li- 
cense including the leaf identification information to the 
second information processing apparatus. 
[001 4] According to a seventh aspect of the invention, 
there is provided a storage medium which stores a com- 
puter-readable program for use with an information 
processing apparatus for providing a license granting 
the use of a content, the program comprising the steps 
of: receiving from a second information processing ap- 
paratus leaf identification information for identifying in a 
key-managed hierarchical tree structure a leaf assigned 
to the second information processing apparatus; and if 
the leaf identification information received in the receiv- 
ing step identifies a leaf subordinate to a first node on a 
given level of the structure, the first node being assigned 
a content provision category, then transmitting the li- 
cense including the leaf identification information to the 
second information processing apparatus. 
[001 5] According to an eighth aspect of the invention, 
there is provided a program executable by a computer 
for controlling an information processing apparatus for 
providing a license granting the use of a content, the 
program causing the computer to carry out the steps of: 
receiving from a second information processing appa- 
ratus leaf identification information for identifying in a 
key-managed hierarchical tree structure a leaf assigned 
to the second information processing apparatus; and if 
the leaf identification information received in the receiv- 



ing step identifies a leaf subordinate to a first node on a 
given level of the structure, the first node being assigned 
a content provision category, then transmitting the li- 
cense including the leaf identification information to the 

5 second information processing apparatus. 

[0016] According to a ninth aspect of the invention, 
there is provided an information processing apparatus 
for offering contents, comprising: a receiving element for 
receiving a content request including content identifica- 

10 tion information for identifying a content; and a transmit- 
ting element for transmitting an encrypted content in- 
cluding an enabling key block decryptable by use of a 
device node key corresponding to a path between a leaf 
subordinate to a first node on a given level of a key- 

15 managed hierarchical tree structure, and the first node 
which is assigned a content provision category. 
[0017] According to a tenth aspect of the invention, 
there is provided an information processing method for 
providing contents, comprising the steps of: receiving a 

20 content request including content identification informa- 
tion for identifying a content; and transmitting an en- 
crypted content including an enabling key block decryp- 
table by use of a device node key corresponding to a 
path between a leaf subordinate to a first node on a giv- 

25 en level of a key-managed hierarchical tree structure, 
and the first node which is assigned a content provision 
category. 

[0018] According to an eleventh aspect of the inven- 
tion, there is provided a storage medium which stores a 
30 computer- readable program for use with an information 
processing apparatus for providing contents, the pro- 
gram comprising the steps of: receiving a content re- 
quest including content identification information for 
identifying a content; and transmitting an encrypted con- 
35 tent including an enabling key block decryptable by use 
of a device node key corresponding to a path between 
a leaf subordinate to a first node on a given level of a 
key-managed hierarchical tree structure, and the first 
node which is assigned a content provision category. 
40 [001 9] According to a twelfth aspect of the invention, 
there is provided a program executable by a computer 
for controlling an information processing apparatus for 
providing contents, the program causing the computer 
to carry out the steps of: receiving a content request in- 
45 eluding content identification information for identifying 
a content; and transmitting an encrypted content includ- 
ing an enabling key block decryptable by use of a device 
node key corresponding to a path between a leaf sub- 
ordinate to a first node on a given level of a key-man- 
so aged hierarchical tree structure, and the first node which 
is assigned a content provision category. 
[0020] According to a thirteenth aspect of the inven- 
tion, there is provided an information processing appa- 
ratus for outputting contents, comprising: a storing ele- 
55 ment for storing a device node key corresponding to an 
extent between a leaf which is assigned to the informa- 
tion processing apparatus and which is subordinate to 
a first node on a given level of a key-managed hierar- 
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ch.cal tree structure, and the first node which is assigned 
a content provision category; a content acquiring ele- 
ment for acquiring an encrypted content including an en- 
abling key block for associating the first node with a root 
key; a decrypting element for decrypting the encrypted 
content by decrypting the enabling key block included 
in the encrypted content acquired by the content acquir- 
ing element, through the use of the device node key 
stored in the storing element; and an outputting element 
deme?""'" 9 ** C ° ntent d6Cfypted ^ the decrypting 
[0021] According to a fourteenth aspect of the inven- 
tion, there is provided an information processing method 
for use w,th an information processing apparatus for out- 
putting contents, the information processing method 
compnsing the steps of: storing a device node key cor- 
responding to an extent between a leaf which is as- 
signed to the information processing apparatus and 
which is subordinate to a first node on a given level of 
a key-managed hierarchical tree structure, and the first 
node which is assigned a content provision category- 
acquinng an encrypted content including an enabling 
key block for associating the first node with a root key- 
decrypting the encrypted content by decrypting the en- 
abling key block included in the encrypted content ac- 
quired in the content acquiring step, through the use of 
the device node key stored in the storing step; and out- 

f^ZS ° 0n,ent decr VP ted in »» decrypting step. 
[0022] According to a fifteenth aspect of the invention 
there is provided a storage medium which stores a com- 
puter-readable program for use with an information 
processing apparatus for outputting contents, the pro- 
gram comprising the steps of: storing a device node key 
corresponding to an extent between a leaf which is as- 
signed to the information processing apparatus and 
which is subordinate to a first node on a given level of 
a key-managed hierarchical tree structure, and the first 
node which is assigned a content provision category- 

k^h. nn9 .f n enCfyPted C ° ntent inc,udin 9 an cabling 
key block for associating the first node with a root key- 
decrypting the encrypted content by decrypting the en- 
abling key block included in the encrypted content ac- 
quired in the content acquiring step, through the use of 
the device node key stored in the storing step; and out- 
putting the content decrypted in the decrypting step 
[0023] According to a sixteenth aspect of the inven- 
tion, there is provided a program executable by a com- 
puter for controlling an information processing appara- 
tus for outputting contents, the program causing the 
computer to carry out the steps of: storing a device node 
key corresponding to an extent between a leaf which is 
assigned to the information processing apparatus and 
which is subordinate to a first node on a given level of 
a key-managed hierarchical tree structure, and the first 
node which is assigned a content provision category- 
acquinng an encrypted content including an enabling 
key block for associating the first node with a root key- 
decrypting the encrypted content by decrypting the en- 



abling key block included in the encrypted content ac- 
quired in the content acquiring step, through the use of 
the device node key stored in the storing step; and out- 
putting the content decrypted in the decrypting step 
[0024] Where the information processing apparatus 
information processing method, and program according 
to the first, second, and fourth aspects of the invention 
are in use, as outlined above, a second information 
processing apparatus is assigned uniquely to a leaf sub- 
10 ordinate to a first node on a given level of a key-man- 
aged hierarchical tree structure, the first node being as- 
signed a content provision category. The second infor- 
mation processing apparatus is provided with a device 
,5 k ^ or : es P ondin 9 to a path between the assigned 
»5 leaf and the first node. 

[0025] Where the information processing apparatus, 

o * < T Pr< ? essin 9 method . program according 
to the fifth, sixth, and eighth aspects of the invention are 
in use, the inventive apparatus receives from a second 
information processing apparatus leaf identification in- 
formation for identifying in a key-managed hierarchical 
tree structure a leaf assigned to the second information 
processing apparatus. If the received leaf identification 
information identifies a leaf that is subordinate to a first 
node on a given level of the tree structure, the first node 
being assigned a content provision category, then the 
inventive apparatus transmits a license including the 
leaf identification information to the second information 
processing apparatus. 

30 f 0 , 026 * Wnere the information processing apparatus 
information processing method, and program according 
to the ninth, tenth, and twelfth aspects of the invention 
are in use, the inventive apparatus receives a content 
request including content identification information for 
identifying a content. In response, the inventive appara- 
tus transmits an encrypted content including an ena- 
bling key block (EKB) decryptable by use of a device 
node key corresponding to a path between a leaf sub- 
ordinate to a first node on a given level of a key-man- 
aged hierarchical tree structure, and the first node which 
is assigned a content provision category 

SS , Wh6re information Processing apparatus, 
"formation processing method, and program according 
to the thirteenth, fourteenth, and sixteenth aspects of 
the invention are in use, the inventive apparatus stores 
a device node key corresponding to an extent between 
a leaf which is assigned to the inventive apparatus and 
which is subordinate to a first node on a given leveTof 

so n«H K ana£ ! ed nierarchical tr ee structure, and the first 
node which is assigned a content provision category 
The apparatus proceeds to acquire an encrypted con- 
tent incuding an enabling key block (EKB) for associat- 
ing the first node with a root key. The encrypted content 
55 1h f T ty decr yP« n 9 ^e enabling key block includ- 
£ ,n the encrypted content by use of the device node 
key. The decrypted content is then output. 
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BRIEF DESCRIPTION OF DRAWINGS 
[0028] 

Fig. 1 Is a block diagram outlining a typical config- 
uration of a content providing system according to 
the invention; 

Fig. 2 is a block diagram showing a typical structure 

of a client included in the system of Fig. 1; 

Fig. 3 is a flowchart of steps constituting a content 

downloading process performed by the client in Fig. 

1; 

Fig. 4 is a flowchart of steps constituting a content 
providing process performed by a content server in- 
cluded in the system of Fig. 1; 
Fig. 5 is a schematic view of a format applicable to 
step S26 in Fig. 4; 

Fig. 6 is a flowchart of steps constituting a content 
reproducing process performed by the client in Fig. 
1; 

Fig. 7 is a flowchart of steps constituting a license 
acquiring process in step S43 of Fig. 6; 
Fig. 8 is a schematic view of a license structure; 
Fig. 9 is a flowchart of steps constituting a license 
providing process performed by a license server in- 
cluded in the system of Fig. 1; 
Fig. 1 0 is a flowchart of detailed steps constituting 
a license renewing process in step S45 of Fig. 6; 
Fig. 11 is a flowchart of steps constituting a license 
renewing process performed by the license server 
in Fig. 1; 

Fig. 12 is an explanatory view of a key structure; 
Fig. 13 is an explanatory view of a category node 
arrangement; 

Fig. 14 is a schematic view illustrating typical cor- 
respondences between nodes and devices; 
Fig. 15A is an explanatory view of an enabling key 
block structure; 

Fig. 1 5B is an explanatory view of another enabling 
key block structure; 

Fig. 16 is an explanatory view showing how an en- 
abling key block is utilized; 

Fig. 17 is a schematic view indicating a typical for- 
mat of the enabling key block; 
Fig. 1 8 is an explanatory view depicting a tag struc- 
ture of the enabling key block; 
Fig. 1 9 is an explanatory view sketching a content 
decrypting process using a device node key (DNK); 
Fig. 20 is a schematic view of a typical enabling key 
block; 

Fig. 21 is an explanatory view picturing how a plu- 
rality of contents are assigned to a single device; 
Fig. 22 is an explanatory view of license categories; 
Fig. 23 is a timing chart explaining how a registering 
process is carried out; 

Fig. 24 is a flowchart of steps constituting a ripping 

process performed by the client; 

Fig. 25 is an explanatory view of a watermark struc- 



ture; 

Fig. 26 is a schematic view of a typical content for- 
mat; 

Fig. 27 is a schematic view of a typical public key 
s certificate; 

Fig. 28 is an explanatory view showing how a con- 
tent is distributed; 

Fig. 29 is a flowchart of steps constituting a content 
check-out process performed by the client; 
10 Fig. 30 is an explanatory view depicting how ena- 
bling key blocks are traced by tag; 
Fig. 31 is a schematic view of a typical enabling key 
block structure; 

Fig. 32 is an explanatory view of a mark structure; 
is Fig. 33 is a flowchart of steps constituting a license 
purchasing process performed by the client; 
Fig. 34 is a flowchart of steps constituting a license 
purchasing process performed by the license serv- 
er; 

20 Fig. 35 is a schematic view of a typical mark struc- 
ture; 

Fig. 36 is a flowchart of steps constituting a certifi- 
cate registering process performed by the client; 
Fig. 37 is a flowchart of steps constituting a certifi- 
es cate registering process performed by the content 
server; 

Fig. 38 is a schematic view of typical group certifi- 
cates; 

Fig. 39 is a flowchart of steps constituting a process 
30 performed by the content server where grouping is 
in effect; 

Fig. 40 is a schematic view of an encrypted content 
key; 

Fig. 41 is a flowchart of steps constituting a process 
35 performed by a client belonging to a group; 

Fig. 42 is a flowchart of steps constituting a process 
performed by a client checking out a license to an- 
other client; 

Fig. 43 is a flowchart of steps constituting a process 
40 performed by a client having a license checked out 
from another client; 

Fig. 44 is a flowchart of steps constituting a repro- 
ducing process performed by a client having a li- 
cense checked out thereto; 
45 Fig. 45 is a flowchart of steps constituting a process 
performed by a client having a license checked in 
from another client; 

Fig. 46 is a flowchart of steps constituting a process 
performed by a client having a license checked in 

so to another client; 

Fig. 47 is an explanatory view showing how a mes- 
sage authentication code (MAC) is generated; 
Fig. 48 is an explanatory view outlining a decrypting 
process of an integrity check value (ICV) generation 

55 key; 

Fig. 49 is an explanatory view illustrating another 
decrypting process of the ICV generation key; 
Fig. 50A is an explanatory view depicting how a li- 
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cense copying process is managed with ICV 

tho'if, ' S an ° ther e *P ian *°<Y view indicating how 
tn > license copying process is managed with ICV- 

Fig. 51 is an explanatory view showing how licenses 
are managed. 
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BEST MODE FOR CARRYING OUT THE INVENTION 

ES3 w' 9 ' 1 ° UtlineS 3 fypicai ^figuration of a con- 
ent Prov.d,ng system according to the invention. Clients 
1-1 and 1-2 (simply called the client 1 hereunder if there 
is no need for distinction therebetween) are connected 
to the mteme. 2. Although oniy two clients are shown 

ems ml j 6XamP,e ° f "* 1 " anv of T 
fOOSul "Tn ?? neCXed 10 ,hS ' n,ernet 2 in P ra o«ce. 
£r!e?3 Til lntemet2isalS0C0 "^ctedwithaconten« 
server 3, a l.cense server 4, and an accounting server 
5. The content server 3 provides contents to the client 

I'Jr^l ^ SerVSr 4 0fferS the c,ient 1 «<»nees fo 
using the contents provided by the content server 3. The 
accounting server 5 performs an accounting process ^ 
garding the c.ient 1 having acquired a license. 
[0031] Any number of content servers 3, license serv- 
ers 4, and accounting servers 5 may be configured and 
connected to the Internet 2 in practice 

E inV S o° W l a tyPiCa ' Stmc,ure of the cli ^t 1 . 
[0033] In Fig. 2, a CPU (central processing unit) 21 

Zm ZTT' PrOC6SSeS USinS P-9'ams 9 held n a 
ROM (read-only memory) 22 or those loaded from a 

Tl g LTJl into a ** M (random access i 

to the CPU 2 A 6PS * h SUPP ' ieS time informa «0" 
da £ !f ♦ " needed> the RAM 23 ma V eccommo- 

pr2essr qU ' red ^ CPU 21 h eXeCUti "9 di — 
A " e " c 'yP ti °n/decryption unit24 encryptscon- 

tent data and decrypts previously encrypted content da- 
ta. A codec un,t 25 encodes content data illustrative^ 
acceding to ATRAC3 (Adaptive Transform Acoustic 
Cod.ng Version 3) standards, and sends the encoded 

memoir ' n,erfaCe 32 ,0 8 se ^onduc,or 

memory 44 ,n a dnve 30 for storage. The codec unit 25 
also decodes encoded data retrieved from the semicon- 
ductor memory 44 in the drive 30 

coS, J!* 6 Sem i conduc,or "^ory 44 is illustratively 
constituted by a Memory Stick (trademark). 

£ CPU 21 ' R ° M 22 ' RAM 23 encryption/ 
decryption un,t24, and codec unit 25 are interconnected 

.r rf ace S 3 3 2: ^ 31 ,S ,Urth6r C ° nneCted ^ 

S J," 6 ! /0 t in,erface 32 is connected with an input 
un 1 26, an output unit 27, a storage unit 28, and a com- 
munication un,t 29. The input unit 26 comprises a key- 
board and a mouse. The output unit 27 is composed of 
a d-spaysuchasaCRToranLCDaswella ssp eakers 
The storage unit 28 is typically made up of a hard d isc 
rZli ^ co, " rnunica,io " "nit 29 is illustratively com- 
posed of a modem or a terminal adapter that executes 



communication processes overthe Internets The com- 
munication unit 29 also exchanges analog or digital sio- 
nals with other clients. <*g'raisig 

5 KSn 1/0 interface 23 is a,so connected to the 

2TJ V* need6d - ThS drive 30 is ,oaded ^th a stor- 
age medium such as a magnetic disc 41 , an optical disc 

9 J ' et °-° pt,caldisc43 .orasemiconductor mem- 
ory 44 where necessary. Computer programs are re- 

"> 'nto the storage unit 28 as needed 

[0039] Although not shown {he contem 

SZTET 4 ' aCC ° Un,in9 SefVer 5 are eac " con- 
tl » « 2 f ?T PU,er havin9 basica,, y the sa^e struc- 
« thl! 31 ° f the C ' ient 1 in Ra - 2 - »" *he description 

r^' 3 ' detai ' S in R9 - 2 wi " ba cited as 
applicable to the content server 3, license server4 and 
accounting server 5 as well 

!he°^Lnt OWtheClient1 ^P^^withacontentfrom 

ess^^"* be described by re,erri " 9 

[0041] The user orders access to the content server 

21 relcT? ''^ ^ 26 - ,n ~P«~. 2 ' CPU 
29 o at I" 81 and 0311868 the communication unit 

* Si S2 thl 8 , C ° ntem S6rVer 3 Via the ,ntemet 2 - 
S ! ,npUtS inform ation 'or designating the 
content to be provided by operating the input uni?26 
rein 5 ^"^^ng information, the CPU 21 
reports the information to the content server 3 through 

30 Seint n ?^' Cati ° n Unit 29 and ^ ,he "^et 2. Upon 

rece pt of the report, the content server 3 returns en- 
crypted content data, as wili be described later w!n re"- 

re'cT °' ^ Step S3 - *• 3i« 
receives the transmitted content data through the com- 
mun.cat.on unit 29. In step S4, the CPU 21 recoTdsTe 

Sf F^ Cribed be ' OW With reference to the f'ow- 
S t^e col J" 8 COn,en, Pr ° Vidin9 process carria d out 
^ dLrrih h SSrVer 3 in c o n j u "otion with the above- 
scrioSn t h PrOC f SS by the dient 1 " ln * ha ^suing de- 
wiHbe cited as applicable to the content server 3 as welf 
[0043] m step S21, the CPU 21 of the content server 
3 waits unti. it is accessed by the client 1 throug^e 

C r mi T atl0n Unit 29 and over *° 'nternet 2 When 
accessed by the c.ient 1 , the CPU 21 reaches stepsS 

£ d c a iS*T^ n T deSi9na,ln9 informati on eenffrom 
1 i^p 32^^ 
» [0044] In step S23, the CPU 21 of the content server 
3 retneves from the storage unit 28 the content oes£ 

S24le y cPU Pi 0 " 3 " 0 " aCqUirSd Ste " s£ " "top 
r PU2l8uppl, ' estheenc 'yPfion/decryptionuntt 
55 28 ^ C ° nt ! nt ^ re,ri6Ved ,rom tne stoTage ul 

iTa « e y U Kt 24 ,0 6nCW ^ SUPP » ad data 
[0045] All content data held in the storage unit 28 have 
already been encoded by the codec un? 25 based on 
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ATRAC3. Any encoded content data retrieved from the 
storage unit 28 are thus encrypted further by the encryp- 
tion/decryption unit 24. 

[0046] Obviously, all content data to be placed in the 
storage unit 28 may be encrypted in advance. In such 
a case, step S24 of Fig. 4 may be skipped. 
[0047] In step S25, the CPU 21 of the content server 
3 adds key information (i.e., enabling key block (EKB) 
and data K EKBC (KC) to be described later by referring 
to Fig. 5) needed to decrypt the encrypted content, and 
a license ID for identifying the license granting the use 
of the content, to a header as part of a format in which 
to transmit the encrypted content data. In step S26, the 
CPU 21 of the content server 3 transmits the content 
encrypted in step S24 and the header furnished with the 
key and license ID in step S25 to the accessing client 1 
through the communication unit 29 and over the Internet 
2. 

[0048] Fig. 5 shows a typical format in which the con- 
tent server 3 provides content data to the client 1 . As 
illustrated in Fig. 5, the format is made up of a header 
and a data part. 

[0049] The header comprises content information, a 
URL (uniform resource locator), a license ID, an ena- 
bling key block (EKB), and data K EKBC (Kc) as the con- 
tent key Kc encrypted by use of a key K EKBC derived 
from the EKB. The EKB will be described later in more 
detail with reference to Figs. 15A and 15B. 
[0050] The content information includes a content ID 
(CID) as information for identifying the content data for- 
matted as data, and a codec method for coding and de- 
coding the content in question. 

[0051] The URL is information denoting the address 
to be accessed in acquiring the license designated by 
the license ID. Illustratively with the system of Fig. 1 , the 
URL stands for the address of the license server 4 from 
which to acquire licenses. The license ID identifies the 
license to be needed in utilizing the relevant content re- 
corded as data. 

[0052] The data part comprises any number of en- 
cryption blocks. Each encryption block is made up of an 
initial vector (IV), a seed, and data EK'c(data) obtained 
by encrypting the content data using a key K'c. 
[0053] The key K's is constituted by a value obtained 
by applying the content key Kc and a randomly estab- 
lished seed (value) to a hash function, as defined by the 
following expression: 

K'c = Hash(Kc, Seed) 

[0054] Each encryption block is furnished with a dif- 
ferent initial vector (IV) and a different seed. 
[0055] The encryption of content data is carried out in 
units of eight bytes. Each eight-byte portion is encrypted 
by use of the encrypted result from the preceding eight- 
byte portion in what is known as CBC (cipher block 
chaining) mode. 



[0056] In CBC mode, the first eight-byte content data 
portion cannot be encrypted using the encrypted result 
from the preceding eight-byte portion. Instead, the first 
eight-byte portion is encrypted by use of the initial vector 

5 IV as the initial value. 

[0057] With CBC mode in effect, even if any one en- 
cryption block is unlawfully decrypted, the other encryp- 
tion blocks will not be decrypted correspondingly. 
[0058] This encryption scheme will be described later 

w in more detail by referring to Fig. 47. 

[0059] This encryption scheme, it should be noted, is 
not limitative of the invention. Alternatively, the content 
data may be encrypted by simply utilizing the content 
key Kc. 

15 [0060] In the manner described, the client 1 can ac- 
quire content data unrestrainedly and free of charge 
from the content server 3. That is, large quantities of 
contents can be distributed in a fairly unconstrained 
manner. 

20 [0061] However, before using any acquired content, 
each client 1 must be in possession of a license corre- 
sponding to the content. How the client reproduces a 
content will now be described by referring to Fig. 6. 
[0062] In step S41 , the CPU 21 of the client 1 acquires 
25 content ID information (CID) designated by the user op- 
erating the input unit 26. The ID information may be con- 
stituted illustratively by a content title and a number 
unique to each of the stored contents. 
[0063] When a given content is designated, the CPU 

30 21 reads a license ID relative to the content (i.e., ID of 
the license for granting the use of the content). The li- 
cense ID is described in the header of the encrypted 
content data, as depicted in Fig. 5. 
[0064] In step S42, the CPU 21 determines whether 

35 or not the license corresponding to the license ID re- 
trieved in step S41 has already been acquired by the 
client 1 and stored in the storage unit 28. If the license 
has yet to be acquired, the CPU 21 goes to step S43 
and performs a license acquiring process. Details of the 

40 license acquiring process will be described later with ref- 
erence to the flowchart of Fig. 7. 
[0065] If in step S42 the license is judged to have been 
acquired already or if the license acquiring process is 
carried out in step S43, then step S44 is reached. In step 

45 S44, the CPU 21 judges whether or not the acquired 
license falls within the corresponding expiration date. 
Whether or not the license has expired is determined by 
comparing the expiration date stipulated in the license 
(which will be described later by referring to Fig. 8) with 

50 the current date and time kept by the timer 20. If the 
license is judged to have expired, the CPU 21 goes to 
step S45 and performs a license renewing process. De- 
tails of the license renewing process will be described 
later by referring to the flowchart of Fig. 1 0. 

55 [0066] If in step S44 the license is judged to be effec- 
tive or if the license is renewed in step S45, then step 
S46 is reached. In step S46, the CPU 21 reads the ap- 
plicable encrypted content data from the storage unit 28 
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2 r6,r,eVed data int0 the RAM 23. In step 
^i 6 ,? SUPP "' eS the encryption/decryption unit 
24 w.th the content data stored in the RAM 23 in units 

uir^rir blocks as shown in ^- 

r«l^ 6Crypt *• data usin 9 the c °ntent key Kc. 
[0067] The content key Kc is obtained (to be de- 
scribed later in more detail by referring to Figs. 15A and 
15B) illustratively as follows: a key K EKBC is first ac- 
quired using a device node key (DNK). The content key 

?bv uT ^^'^ from thS data Kek bc(Kc) (see Fig. 
5) by use of the acquired key K EKBC . 

[0068] In step S48, the CPU 21 supplies the codec 
unit 25 w.th the content data decrypted by the encryp- 
tion/decryption unit 24, and causes the codec unit 25 to 
decode the supplied data. The CPU 21 then sends the 
data decoded by the codec unit 25 to the output unit 27 
through the I/O interface 32. In turn, the output unit 27 
converts the received digital data to analog format for 
audio output through the speakers. 
[0069] How the license acquiring process is per- 
formed in step S43 of Fig. 6 will now be described in 
detail with reference to the flowchart of Fig. 7 
[0070] The client 1 accesses the license server 4 in 
advance for a registering process whereby service data 
are acquired, including a leaf ID, a DNK (device node 
key), a pnvate key paired with a public key for the client 
1. a public key of the license server 4, and certificates 
of he respective public keys. The registering process 
by the cl,ent 1 will be described later in detail by referring 
to Fig. 23. a 

[0071] The leaf ID represents identification informa- 
tion assigned to each client. The device node key (DNK) 
rs required in decrypting an encrypted content key Kc 
included in the enabling key block (EKB) corresponding 
to the license of interest (DNK will be described later bv 
refernng to Fig. 12). y 

£f k 21 w lna,epS61 of Fig. 7, the CPU 21 acquiresfrom 
n w . f ( ' 9 - 5) the URL co "esponding to the license 
k 'ff " t,fy,n 9 tne desir *d "cense. As described above 
the URL denotes the address to be accessed in obtain- 
ing the license associated with the license ID also de- 
scnbed in the header. In step S62, the CPU 21 accesses 

Si.J! ^ in S,6P S61 ■ More ^cifically, the 
CPU 21 gains access to the license server4 through the 
communication unit 29 and over the Internet 2. At this 
point, the license server 4 requests the client 1 to input 
license-designating information for designating the li- 
cense to be purchased (i.e., license needed for the use 
of the content), a user ID, and a password (see step 
SI 02 in F.g. 9). The CPU 21 displays the request on the 
display of the output unit 27. Given the display, the user 
operates the input unit 26 to enter the license-designat- 
ing information, user ID, and password. The user ID and 
password have been acquired in advance by the user 
of the client 1 having accessed the license server 4 over 
the Internet 2. 

[0073] In step S63, the CPU 21 acquires the license- 
designating information from the input unit 26. In step 



S64, the CPU 21 obtains the previously acquired user 
ID and password. In step S65, the CPU 21 causes the 
communication unit 29 to transmit to the license server 
4 over the Internet a license request comprising the en- 
tered user ID, password, license-designating informa- 
tion, and a leaf ID contained in the service data (to be 
described later) v 
[0074] in turn, as will be described later with reference 

io h° 9 ; 1 ! ' iCenSe Server 4 either tra "smits the license 
based on the user ID, password, and license-designat- 
ing information (in step S109), or does not transmit the 
•cense if relevant conditions are not met (in step S112) 
[0075] In step S66, the CPU 21 judges whether or not 
he license has arrived from the license server 4. If the 

whThl' S , jUd9ed tranSmit,ed ' Step S67 is cached in 
which me license is fed to the storage unit 28 for storage 

S lf in h steD 5366 *ne license is not judged trans- 
mitted from the license server 4, then the CPU 21 aoes 

r°pn e , P 1 S6 i' 0f 6rr0r handlin 9- M °re specifically the 
CPU 21 inhibits any content reproducing process be- 
cause the license for granting the use of the content in 
question is not acquired. 

[0077] It is only after the client 1 has obtained the li- 
cense applicable to the license ID attached to the con- 
tent date .n carrying out the above steps, can the content 
be used for reproduction. 

[0078] The license acquiring process of Fig. 7 may al- 
tentatively be carried out before each user proceeds to 
30 obtain any content. 

! iCenSe 0ffered t0 the client 1 contains use 
conditions, a leaf ID, and other data items as shown in 

»'Q' 8. 

[0080] The use conditions include such information as 
a use time limit within which the content may be used 
a download time limit within which the content may be 
downloaded, a maximum number of times the content 
may be copied, the number of times the content has 

ao th™ eC , °u S ° ' ar ' 3 maximum num oer of times 
the content may be checked out, the right to record the 
content to a CD-R, a maximum number of copies that 

SUT l. m . ad8 ° f the COn,ent to PDs ^ole devices), 
the right to purchase the license outright, and the duty 

45 «™!, P "t 6 ' 09S ' a " wording to the license in question. 
[0081] Described below with reference to the flow- 
chart of Fig. 9 is how the license server 4 performs a 
license providing process in conjunction with the license 
acquinng process carried out by the client 1 in Fig 7 In 
th.s case, too. structural details in Rg. 2 will be cited as 
*> applicable to the license server 4 as well 

[0082] In step S1 01 , the CPU 21 of the license server 
4 waits until it is accessed by the client 1. The CPU 21 
goes to step S102 when accessed by the client 1 In 
step S102, the CPU 21 requests the accessing c ent ? 
* to transmit a user ID, a password, and license-designat- 
ing information. As described above, the user ID, pass- 
ESX 1 * T liC6nSe - desian ating information (i.e., 
license ID) are transmitted from the client 1 in step S65 
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of Fig. 7. In turn, the CPU 21 of the license server 4 
receives and acquires what has been transmitted 
through the communication unit 29. 
[0083] In step S1 03, the CPU 21 of the license server 

4 gains access to the accounting server 5 through the 
communication unit 29 and requests the accounting 
server 5 to perform a credit authorization process re- 
garding the user corresponding to the user ID and pass- 
word. Given the credit authorization request from the li- 
cense server 4 over the Internet 2, the accounting server 

5 examines the payment history or other suitable 
records of the user defined by the user ID and password. 
A check is made illustratively to see if the user in ques- 
tion has failed to pay the price of any license in the past. 
If the user is not judged to have such nonpayment 
records, the accounting server 5 transmits credit author- 
ization data; if the user is judged to have any nonpay- 
ment records, the accounting server 5 transmits credit 
rejection data. 

[0084] In step S1 04, the CPU 21 of the license server 
4 determines whether or not the accounting server 5 has 
returned the credit authorization data for granting the 
license to the user. If the credit authorization data are 
judged returned, step S105 is reached. In step S105, 
the CPU 21 retrieves from the storage unit 28 one of the 
stored licenses which corresponds to the license-desig- 
nating information acquired in step S102. Each license 
held in the storage unit 28 has a license ID, version in- 
formation, a date and time of preparation, and an expi- 
ration date described therein beforehand. In step S106, 
the CPU 21 adds the received leaf ID to the license. In 
step S107, the CPU 21 selects the use conditions cor- 
responding to the license selected in step S105. If the 
use conditions were designated in step S102 by the us- 
er, the designated use conditions may be added as 
needed to the previously prepared use conditions. The 
CPU 21 furnishes the license with the use conditions 
thus selected. 

[0085] In step S108, the CPU 21 affixes a digital sig- 
nature to the license by use of a private key from the 
license server 4. This step generates a license whose 
structure is shown in Fig. 8. 

[0086] In step S109, the CPU 21 of the license server 
4 transmits the license (shown structurally in Fig. 8) to 
the client 1 through the communication unit 29 and over 
the Internet 2. 

[0087] In step S110, the CPU 21 of the license server 
4 places into the storage unit 28 the license that has just 
been transmitted (including the use conditions and leaf 
ID) in correspondence with the user ID and password 
acquired in step S102. In step S111, the CPU 21 carries 
out an accounting process. More specifically, through 
the communication unit 29, the CPU 21 requests the ac- 
counting server 5 to carry out an accounting process re- 
garding the user corresponding to the user ID and pass- 
word. Given the accounting request, the accounting 
server 5 bills the user for the license. If the user fails to 
pay the billed amount, the user from then on will be 



banned from acquiring any further license that may be 
requested. 

[0088] In such a case, the accounting server 5 returns 
in step S104 the credit rejection data banning the grant- 

5 ing of the requested license. Step S1 04 is then followed 
by step S112 in which the CPU 21 performs error han- 
dling. More specifically, the CPU 21 of the license server 
4 outputs to the client 1 having gained access through 
the communication unit 29 a message saying that the 

10 license cannot be granted to the user. The CPU 21 then 
terminates the process. 

[0089] In this case, the user cannot utilize the content 
(i.e., unable to decrypt the content), having failed to re- 
ceive the license for the reason above. 

15 [0090] Fig. 10 is a flowchart of detailed steps consti- 
tuting a license renewing process in step S45 of Fig. 6. 
Steps S131 through S 135 in Fig. 10 are basically the 
same as steps S61 through S65 in Fig. 7, except that in 
step S1 33 the CPU 21 acquires the ID of the license that 

20 is not to be purchased but to be renewed. In step S1 35, 
the CPU 21 transmits to the license server 4 the ID of 
the license to be renewed together with the user ID and 
password. 

[0091] In response to the transmission from the client 

25 1 in step S135, the license server 4 proposes use con- 
ditions as will be described later (in step S153 of Fig. 
11). In step S136, the CPU 21 of the client 1 receives 
the proposed use conditions from the license server 4 
and forwards the received conditions to the output unit 

30 27 for display. The user may select desired use condi- 
tions from those proposed or may add new conditions 
thereto by operating the input unit 26. In step S137, the 
CPU 21 transmits to the license server 4 sign-up data 
for purchasing the selected use conditions (i.e., condi- 

35 tions for renewing the license). Upon receipt of the sign- 
up data, the license server 4 returns definitively pro- 
posed use conditions (in step S154 of Fig. 11). In step 
S138, the CPU 21 of the client 1 acquires the use con- 
ditions from the license server 4. In step S1 39, the CPU 

40 21 substitutes the newly acquired use conditions for the 
currently stored use conditions corresponding to the li- 
cense in the storage unit 28. 

[0092] Fig. 11 is a flowchart of steps constituting a li- 
cense renewing process performed by the license serv- 

45 er 4 in conjunction with the license renewing process 
carried out by the client 1 as described above. 
[0093] In step S1 51 , the CPU 21 of the license server 
4 is first accessed by the client 1 . In step S1 52, the CPU 
21 receives the license-designating information trans- 

50 mitted by the client 1 in step S1 35 together with a license 
renewal request 

[0094] In step S153, given the license renewal re- 
quest, the CPU 21 retrieves from the storage unit 28 the 
use conditions (to be renewed) corresponding to the li- 
55 cense in question. The retrieved use conditions are 
transmitted to the client 1 . 

[0095] Upon receipt of the use conditions thus pro- 
posed, the client 1 signs up for the purchase of the con- 
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ditions in step S137 of Fig. 10 as described above In 
step S1 54, the CPU 21 of the license server 4 generates 
data corresponding to the use conditions that the client 
1 has signed up to purchase, and transmits the gener- 
ated data to the client 1 . In turn, the client 1 renews the 
use conditions of the currently registered license by uti- 
lizing the use conditions received in step S139 as de- 
scribed above. 

[0096] The inventive system, as shown in Fig. 12, 
manages the keys of devices and licenses based on the 
principle of what is known as broadcast encryption (refer 
to Japanese Patent Laid-open No. 2001-352321). The 
keys make up a hierarchical tree structure in which the 
leaves at the bottom level correspond to the keys of in- 
dividual devices. In the example of Fig. 12, keys are gen- 
erated to represent 16 devices or licenses numbered 0 
through 15. 

[0097] Each key is defined so as to correspond with 
each of the nodes (shown as circles in the figure) con- 
stituting the tree structure. In this example, a root key 
KR denotes the root node at the highest level; keys K0 
and K1 correspond to the nodes at the second-highest 
level; keys K00 through K11 represent the nodes at the 
third-highest level; and keys K000 through K111 match 
the nodes at the fourth-highest level. Keys K0000 
through K1111 correspond to the leaves representative 
of the nodes at the bottom level (i.e., device nodes). 
[0098] In this hierarchical structure, the key immedi- 
ately above, say, keys K001 0 and K001 1 is a key K001 ; 
and the key immediately above keys K000 and K001 is 
a key K00. In like manner, keys K00 and K01 are topped 
by a key KO, and keys KO and K01 are topped by the 
route key KR. 

[0099] The key granting the use of any content is man- 
aged in the form of a key corresponding to each node 
on a single path ranging from a given leaf at the bottom 
level to the root node at the topmost level. For example 
the keys granting the use of a content based on the li- 
cense relative to node No. 3 (leaf ID) are managed in 
the form of a path comprising the keys K0011, K001 
K00, KO, and KR. ' 
[0100] The inventive system, as shown in Fig. 13, 
manages the keys of devices and licenses using a key 
system based on the principle depicted in Fig. 12. In the 
example of Fig. 13, nodes at "8 + 24 + 32" levels con- 
stitute a tree structure in which each of the nodes rang- 
ing from the route node to the eighth-highest level is 
matched with a given category of devices. Illustratively, 
one category may comprise devices each employing a 
specific semiconductor memory such as Memory Stick; 
another category may include devices designed to re- 
ceive digital broadcasts. To any one of such category 
nodes applies this system (indicated as the T system in 
the figure) acting as a license-managing system. 
[0101] That is, licenses are made to correspond with 
the keys representing the nodes at the 24 levels below 
the node of this system (T system). In this case, it is 
possible to define as many as 2 to the 24th power (about 



1 6 million) licenses. If the lowest 32 levels are also taken 
into account, it is possible to define as many as 2 to the 
32nd power (about 4 billion) users (or clients). A device 
node key (DNK) refers to the key corresponding to each 
5 of the nodes on a given path ranging from any one of 
the leaves denoting the nodes at the lowest 32 levels to 
the root node. A leaf ID denotes the ID of any one of the 
leaves at the bottom level of the structure. 
[0102] Each of the keys of devices and licenses cor- 
10 responds to one of the paths made up of the nodes at 
the 64 (= 8 + 24 + 32) levels. For example, a content 
key denved from a particular content through encryption 
is encrypted by use of the keys corresponding to the 
nodes making up the path assigned to the license of in- 
15 terest. The key at a given level is encrypted using the 
keys at the immediately lower level before being placed 
into an enabling key block (EKB; to be discussed later 
by referring to Figs. 15A and 15B). The DNK is not 
placed within the EKB but is described in the service 
20 data supplied to the client 1 of the user. Using the DNK 
contained in the service data, the client 1 decrypts that 
key of the immediately higher level which is described 
in the EKB (see Figs. 15A and 15B) distributed along 
with the content data. Using the key thus decrypted the 
25 client 1 decrypts that key at the next higher level which 
is also described in the EKB. This decrypting process is 
repeated by the client 1 so as to obtain all keys belong- 
ing to the path in question. 

[0103] Fig. 14 shows a typical hierarchical tree struc- 
30 ture for classifying categories. The highest level in the 
hierarchical tree structure of Fig. 14 is a root key KR 
2301 followed by node keys 2302 at intermediate levels 
Leaf keys 2303 are defined at the bottom level of the 
structure. Each device is assigned its own leaf key, a 
35 series of node keys ranging from the leaf key to the root 
key, and the root key. 

[0104] The nodes at the M-th highest level (M = 8 in 
the example of Fig. 13) are defined as category nodes 
2304. That is, each of the nodes at the M-th highest level 
40 is regarded as a node in which to establish a device of 
a specific category. Any one of the category nodes at 
the M-th highest level tops those nodes and leaves at 
the (M+1)th highest and subsequent levels which are 
associated with devices subsumed in the category in 
45 question. 

[01 05] For example, a node 2305 at the M-th highest 
level in Fig. 14 is set for the category called "Memory 
Stick (trademark)." All nodes and leaves under this node 
are used exclusively to establish various devices each 
50 utilizing Memory Stick. In other words, the nodes and 
leaves under the node 2305 are defined as a set of 
nodes and leaves associated with devices classified in 
the Memory Stick category. 

[0106] Further a subcategory node 2306 may be es- 
55 tablished illustratively several levels below the M-th 
highest level. In the example of Fig. 14, a "reproduction- 
only device- node 2306 is shown established two levels 
below the "Memory Stick" category node 2305 as a sub- 
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category node subsumed in the category of the Memory 
Stick-using devices. Immediately below the "reproduc- 
tion-only device" subcategory node 2306 is a node 2307 
for establishing a telephone with music reproduction ca- 
pability; the node 2307 is subsumed in the "reproduc- 5 
tion-only device" subcategory. Immediately below the 
"telephone with music reproduction capability" category 
are a "PHS° node 2308 and a "mobile telephone" node 
2309, both subsumed in the "telephone with music re- 
production capability" category. ™ 
[0107] The categories and subcategories are not lim- 
ited to the types of devices alone; they may also be ap- 
plied to nodes managed by manufacturers, content pro- 
viders, banking or settlement organizations or the like 
in their unique manner in the form of processing units, 15 
jurisdictional units, units of provided services, or any 
other suitable units (called entities hereunder). For ex- 
ample, one category node may be established as the 
highest-level node dedicated to a game console XYZ 
marketed by a game console manufacturer. In this case, 20 
the manufacturer can market the game console XYZ by 
furnishing it with entities denoted by node keys or leaf 
keys that come under the topmost node. Thereafter, in 
distributing or renewing encrypted contents or various 
keys, the manufacturer may generate enabling key 25 
blocks (EKB) each constituted by any of the node keys 
or leaf keys under the highest-level node key in order to 
distribute data that can be used only on the devices cor- 
responding to the nodes or leaves involved. 
[0108] As described, where one node tops the other 30 
nodes defined as categories or subcategories sub- 
sumed in the highest node, a manufacturer, a content 
provider or any other organization managing the tree 
structure made up of these nodes may generate unique- 
ly defined enabling key blocks (EKB) each covering 35 
nodes leading up to the highest-level node and may dis- 
tribute the generated blocks to any devices belonging 
to the subordinate nodes under the topmost node. In 
that setup, any key may be renewed in a manner totally 
independent of the devices belonging to any other cat- *o 
egory except the topmost node. 

[0109] For example, in the tree structure of Fig. 12, 
four devices 0, 1 , 2 and 3 contained in a group possess 
common keys K00, K0 and KR as their node keys. This 
shared node key structure may be utilized in providing 45 
a common content key to the devices 0, 1 , 2 and 3 only. 
If the shared node key K00 is established as a content 
key, only the devices 0,1,2 and 3 may be assigned the 
common content key without being furnished with any 
new key. As another example, suppose that a new con- so 
tent key Kcon is encrypted using the node key K00 to 
generate a value Enc(K00, Kcon) which is then distrib- 
uted to the devices 0, 1 , 2 and 3 over a network or by 
use of suitable storage media. In that case, solely the 
devices 0, 1 , 2 and 3 can acquire the content key Kcon 55 
by decrypting the encrypted value Enc(K00, Kcon) using 
the shared node key K00. The notation Enc(Ka, Kb) rep- 
resent the data obtained by encrypting data Kb with data 



Ka. 

[0110] Suppose that at a given point "t" the keys 
K0011, K001, K00, K0 and KR owned by the device 3 
are found to be exposed by a hacker through analysis. 
In that case, the device 3 needs to be isolated from the 
system in order to protect data exchanged within the 
system (i.e., in the group of devices 0, 1 , 2 and 3). This 
requires replacing the node keys K001 , K00, K0 and KR 
with new keys K(t)001, K(t)00, K(t)0 and K(t)R respec- 
tively and informing the devices 0, 1 and 2 of the re- 
newed keys. The notation K(t)aaa indicates a renewed 
key of a generation T derived from a key Kaaa. 
[011 1] How renewed keys are distributed will now be 
described. The key renewal process is carried out illus- 
tratively by furnishing the devices 0, 1 and 2 with a table 
composed of block data called an enabling key block 
(EKB), shown in Fig. 15A, distributed over the network 
or by use of suitable storage media. Each enabling key 
block (EKB) is constituted by encryption keys that are 
used to distribute renewed keys to the devices corre- 
sponding to the leaves (i.e., nodes at the bottom level) 
in the tree structure such as that in Fig. 12. The enabling 
key block (EKB) may also be called a key renewal block 
(KRB). 

[0112] The enabling key block (EKB) shown in Fig. 
15A constitutes block data having a data structure in 
which only the devices needing to have their node keys 
renewed are allowed to do so. The example of Fig. 15A 
is the block data prepared in such a manner as to dis- 
tribute renewed node keys of the generation "t" to the 
devices 0, 1 and 2 in the tree structure of Fig. 12. As is 
evident in Fig. 12, the devices 0 and 1 need renewed 
node keys K(t)00, K(t)0 and K(t)R while the device 2 re- 
quires renewed node keys K(t)001, K(t)00, K(t)0 and K 
(t)R. 

[01 1 3] As indicated by the EKB in Fig. 1 5A, each EKB 
contains a plurality of encryption keys. The encryption 
key in the bottom row of Fig. 15A is Enc(K0010, K(t)001) 
representative of the renewed node key K(t)001 en- 
crypted by use of the leaf key K0010 owned by the de- 
vice 2. The device 2 acquires the renewed node key K 
(t)001 by decrypting the encryption key Enc(K0010, K 
(t)001 ) using its own leaf key K001 0. The renewed node 
key K(t)001 obtained through such decryption may then 
be used to decrypt another encryption key Enc(K(t)001 , 
K(t)00) in the second row from the bottom of Fig. 15A; 
the decryption yields another renewed key K(t)00. 
[0114] Likewise, another encryption key Enc(K(t)00, 
K(t)0) in the second row from the top in Fig. 15A is de- 
crypted to provide a renewed node key K(t)0; the re- 
newed node key K(t)0 is then used to decrypt another 
encryption key Enc(K(t)0, K(t)R) in the topmost row of 
Fig. 15A to produce a renewed root key K(t)R. 
[0115] Meanwhile, the node key K000 is not subject 
to renewal. What the nodes 0 and 1 need as renewed 
node keys are the keys K(t)00, K(t)0 and K(t)R. The 
nodes 0 and 1 acquire the renewed node key K(t)00 by 
decrypting the encryption key Enc(K000, K(t)00) in the 
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third row from the top in Fig. 15A using the node key 
K000 included in the device node keys. In like manner, 
the encryption key Enc(K<t)00, K(t)O) in the second row 
from the top in Fig. 15A is decrypted so as to provide 
the renewed node key K(t)0; the encryption key Enc(K 
(t)0, K(t)R) in the top row of Fig. 15A is decrypted in or- 
der to produce the renewed root key K(t)R. This is how 
the devices 0, 1 and 2 can obtain the renewed key K(t)R. 
[01 16] In Fig. 1 5, each of the indexes in the left-hand 
side column stands for an absolute address of a node 
key or a leaf key used as the decryption key for decrypt- 
ing the corresponding encryption key listed in the right- 
hand side column. 

[0117] Suppose that renewal of the node keys K(t)0 
and K(t)R at the upper levels of the tree structure in Fig. 
12 is not necessary and that only the node key K00 
needs to be renewed. In that case, the enabling key 
block (EKB) of Fig. 15B may be used to distribute the 
renewed node key K(t)00 to the devices 0, 1 and 2. 
[01 18] The EKB shown in Fig. 15B is effective where 
a renewed content key is distributed so as to be shared 
within a specific group of devices. As an example, sup- 
pose that the devices 0, 1 , 2 and 3 forming a group en- 
closed by dotted lines in Fig. 12 utilize a particular stor- 
age medium and that they need a renewed common 
content key K(t)con. In that case, a renewed node key 
K(t)00 is first derived from the node key K00 shared by 
the devices 0, 1, 2 and 3. The renewed node key K(t)00 
is then used to encrypt the renewed content key K(t)con 
generating data Enc(K(t)00, K(t)con). The encrypted da- 
ta Enc(K(t)00, K(t)con) are distributed to the relevant de- 
vices together with the EKB shown in Fig. 1 5B. This dis- 
tribution process ensures distribution of the data which 
can be used only by the devices involved and which can- 
not be decrypted by any device in any other group, such 
as device 4. 

[01 1 9] Illustratively, the devices 0, 1 and 2 can obtain 
the content key K(t)con in effect at time "f by decrypting 
the encrypted data using the key K(t)00 derived from the 
EKB. 

[0120] Fig. 16 schematically shows an example in 
which the content key K(t)con in effect at time V is ac- 
quired. In this example, the renewed common content 
key K(t)con is encrypted using the renewed node key K 
(t)00 to produce encrypted data Enc(K(t)00, K(t)con). 
The encrypted data are sent on a storage medium to the 
device 0 for processing along with the EKB shown in 
Fig. 1 5B. This is an example where EKB-based encrypt- 
ed message data are employed as the content key K(t) 
con. 

[0121] As shown in Fig. 16, the device 0 first gener- 
ates the node key K(t)00 through the EKB process de- 
scribed above using the EKB at time t stored in the stor- 
age medium and the node key K000 included in the DNK 
previously stored in the device itself. The device 0 then 
decrypts the renewed content key K(t)con using the re- 
newed node key K(t)00 decrypted, encrypts the decrypt- 
ed content key K(t)con using the leaf key K0000 specific 



to the device, and stores the encrypted key. 
[01 22] Fig. 1 7 depicts a typical format of the enabling 
key block (EKB). In the format of Fig. 17, a version 601 
is an identifier indicating the version of this enabling key 
5 block. The version 601 has two functions: to identify the 
most recent EKB, and to specify correspondence with 
the content. A depth 602 indicates how deep the level 
of a destination device for EKB distribution is in the hi- 
erarchical tree structure, the device receiving the dis- 
10 tnbuted enabling key block (EKB). A data pointer 603 
points to the position of a data part 606 in the EKB. A 
tag pointer 604 and a signature pointer 605 point to the 
positions of a tag part 607 and a signature 608 respec- 
tively. 

w [0123] The data part 606 accommodates data pre- 
pared illustratively by encrypting the node keys to be re- 
newed. For example, the data part 606 may store en- 
cryption keys regarding the renewed node keys shown 
in Fig. 16. 

20 [0124] The tag part 607 comprises tags that indicate 
the positions of the encrypted node keys and leaf keys 
contained in the data part 606. How the tags are fur- 
nished will now be described by referring to Fig. 18. 
[0125] Fig. 18 depicts how the enabling key block 
& (EKB) explained above with reference to Fig. 1 5A is typ- 
ically distributed as data. The data, shown in tabular 
form in Fig. 1 8, include a top node address indicative of 
the top node included in the encryption keys. In this ex- 
ample, the top node address is KR because the re- 
30 newed key K(t)R of the root key is included. Here, the 
data Enc(K(t)0, K(t)R) in the highest row of the table cor- 
respond to a position P0 in the hierarchical tree structure 
of Fig. 18. The data Enc(K(t)00, K(t)0) in the next-high- 
est row of the table correspond to a position POO at the 
3* lower left of the preceding data position in the tree struc- 
ture. If data are present below a given position in the 
tree structure, the tag for that position is set to 0; if data 
are absent, the tag for the position is set to 1. The tag 
format is given as {left (L) tag, right (R) tag}. In the po- 
40 s,tion po ° at the lower left of the position P0 correspond- 
ing to the highest-row data Enc(K(t)0, K(t)R) in the table 
of Fig. 18, data exist and thus the left tag is set to 0 for 
the position P0. On the other hand, data are absent at 
the lower right of the position P0 so that the right tag is 
*5 set to 1 for that position. In this manner, all data are fur- 
nished with tags and are arranged in tabular form as 
shown in Fig. 18, with the data in rows and the tags in 
columns. 

[0126] Tags are established to indicate where a given 
50 data item Enc(Kxxx, Kyyy) is positioned in the tree struc- 
ture. Whereas key data Enc(Kxxx, Kyyy), ... held in the 
data part 606 are merely a series of encrypted data the 
positions of the encryption keys representing the data 
can be determined in the tree structure through the use 
55 of the above-described tags. If the tags were not used 
the data could still be structured as 

0: Enc(K(t)0, K(t)R) 
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00: Enc(K(t)00, K(t)O) 
000: Enc(K((t)000, K(t)OO) 



using the node indexes relative to the encrypted data as 
explained above with reference to Figs. 15A and 15B. 
However, such an index-based data structure spawns 
huge quantities of redundant data, which can be detri- 
mental to efficient data distribution over the network. By 
contrast, where tags are used as index data indicating 
where the keys are positioned, the key positions can be 
determined with a significantly reduced amount of data. 
[0127] Returning to Fig. 17, the EKB format will be fur- 
ther explained. A signature 608 denotes a digital signa- 
ture affixed illustratively by a key management center (i. 
e. f license server 4), a content provider (content server 
3) or a banking or settlement organization (accounting 
server 5) having issued the enabling key block (EKB). 
The device that has received the EKB authenticates the 
signature to ascertain that the EKB has been issued by 
a legitimate EKB-issuing party. 

[0128] Fig. 19 summarizes the process in which a 
content supplied by the content server 3 is used on the 
basis of the relevant license acquired from the license 
server 4. 

[01 29] As illustrated, the content is first provided from 
the content server 3 to the client 1. The client 1 is then 
furnished with the license from the license server 4. The 
content is encrypted (Enc(Kc, Content)) using a content 
key Kc. The content key Kc is encrypted (Enc(KR, Kc)) 
using the root key KR (obtained from the EKB and cor- 
responding to the key K EKBC in Fig. 5). The encrypted 
content key together with the EKB is added to the en- 
crypted content that is offered to the client 1. 
[0130] The EKB in Fig. 19 contains the root key KR 
that can be decrypted using a DNK (device node key) 
as shown in Fig. 20. The client 1 can thus obtain the root 
key KR from the EKB using the DNK contained in the 
service data. The content key Kc is decrypted from the 
encrypted content key Enc(KR, Kc) by use of the root 
key KR. The content key Kc is then used to decrypt the 
content from the encrypted data Enc(Kc, Content). 
[0131] As described, where the DNK is assigned in- 
dividually to each client 1 , the license of a given client 1 
can be revoked independently on the basis of the prin- 
ciple described above with reference to Figs. 12, 15A 
and 15B. 

[01 32] When each license is distributed together with 
a leaf ID to the client 1, the client 1 brings the service 
data into correspondence with the license. Such corre- 
spondence helps prevent illegal copying of the license. 
[01 33] Where a client-addressed certificate and a pri- 
vate key are distributed as the service data to each cli- 
ent, the end user at the client can prepare a content that 
is resistant to illegal copying through the use of the serv- 
ice data. 

[0134] How the certificate and private key are utilized 
will be described later with reference to the flowchart of 



Fig. 29. 

[0135] As described above with reference to Fig. 13, 
a given category node may be established to bring the 
inventive content distribution system for managing li- 
5 censes into correspondence with a category of devices 
that utilize diverse contents. That means the same de- 
vice may be assigned a plurality of DNKs. It follows that 
contents of different categories can be managed by a 
single device. 

10 [0136] Fig. 21 shows how such content management 
is carried out. In the setup of Fig. 21 , a device D1 retains 
service data and a license for using a content 1 that is 
assigned DNK1 according to the inventive principle of 
the content distribution system. At the same time, the 

15 device D1 may also have a content 2 placed in a Mem- 
ory Stick after it is ripped from a CD, the content 2 being 
assigned DNK2. In this case, the device D1 can concur- 
rently deal with different contents, that is content 1 and 
content 2, distributed according to different systems (i. 

20 e., the content distribution system and the device man- 
agement system). The arrangement above is not adopt- 
ed if the currently assigned DNK is deleted before a new 
DNK is assigned so that the device in question is always 
associated with a single DNK. 

25 [0137] In the tree structure of Fig. 13, each of the tri- 
angles at the lowest 32 levels may illustratively be as- 
signed a license category 1 and a license category 2 
shown in Fig. 22. This means that any single category 
may be divided into subcategories for better manage- 

30 ment covering detailed data items such as the genre of 
the content, the disc label involved, the distributor's 
name, the type of distribution service, the source of the 
content, and a specific manner in which the content is 
offered. 

35 [0138] In the example of Fig. 22, a license category 1 
is shown covering the genre of jazz and a license cate- 
gory 2 the genre of rock and roll. The license category 
1 is matched with contents 1 and 2 which have a license 
ID of 1 each and which are distributed to users 1 , 2 and 

40 3. The license category 2 comprises contents 3, 4 and 
5 which having a license ID of 2 each and which are 
provided to the users 1 and 3. 

[0139] In this setup, keys can be managed independ- 
ently in units of categories according to the invention. 

45 [0140] Also according to the invention, it is possible 
to have DNKs downloaded through the license server 4 
to individual devices or storage media at the time of a 
registering process, instead of having the DNKs incor- 
porated in devices or embedded on storage media be- 

50 forehand. This makes it possible to implement a system 
for allowing users to acquire keys. 
[0141] How the above-mentioned registering process 
is performed by the client 1 will now be described with 
reference to Fig. 23. 

55 [0142] Instep S161, the CPU 21 of the client 1 causes 
the communication unit 29 to transmit a service data re- 
quest to the license server 4. In step S165, the CPU 21 
of the license server 4 receives the service data request 
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through the communication unit 29. In step S166, the 
CPU 21 of the license server 4 transmits a user infor- 
mation request to the client 1 through the communica- 
tion unit 29. 

[0143] In step S162, the CPU 21 of the client 1 re- 
ceives the user information request through the commu- 
nication unit 29. In turn, the CPU 21 causes the output 
unit 27 to display a message prompting the user to enter 
user information. Upon viewing the message, the user 
operates the keyboard or the like to enter the user infor- 
mation such as the user's personal information and ac- 
counting information into the input unit 26. In step S1 63, 
the CPU 21 of the client 1 transmits the user-input infor- 
mation to the license server 4 through the communica- 
tion unit 29. 

[0144] In step S167, the CPU 21 of the license server 
4 receives the user information through the communi- 
cation unit 29. In step S168, the CPU 21 assigns the 
client 1 to any one of the unassigned leaves below the 
node of the category corresponding to the license server 
4, and generates a device node key in the form of a set 
of node keys assigned to the nodes along the path rang- 
ing from the leaf assigned to the client 1 to the node 
corresponding to the category of the license server 4. 
The CPU 21 then generates service data by putting to- 
gether the device node key generated as described, the 
leaf ID of the leaf assigned to the client 1 , a private key 
of the client 1 , a public key paired with the private key 
of the client 1, a public key of the license server, and 
certificates of the public keys. In step S169, the CPU 21 
of the license server 4 transmits the generated service 
data to the client 1 through the communication unit 29 
and causes the drive 30 to record the user information 
to an appropriate storage medium such as a hard disc 
in correspondence with the leaf ID. 
[0145] In step S164, the CPU 21 of the client 1 re- 
ceives the service data through the communication unit 
29. In turn, the CPU 21 causes the encryption/decryp- 
tion unit 24 to encrypt the received service data and 
causes the drive 30 to write the encrypted data to a suit- 
able storage medium such as the hard disc. 
[0146] In the manner described, the license server 4 
registers the client 1 and its user. With the registration 
completed, the client 1 can receive service data includ- 
ing the device node key necessary for utilizing a desired 
content distribution service. 

[0147] It is preferred that a content, once prepared, 
be made usable in any applications regardless of the 
way it is used. Illustratively, the same content should 
preferably be used in different content distribution serv- 
ices or irrespective of the domain use status differing 
from one situation to another. According to this inven- 
tion, the license server 4 acting as a certificate authority 
provides each user (i.e., client 1) with a private key and 
a certificate of a public key corresponding to the private 
key. Each user prepares a signature using the distribut- 
ed private key and affixes the signature to the content 
to attest its integrity, whereby any tampering of the con- 



tent is prevented. 

[0148] How the above process is carried out will now 
be described by referring to the flowchart of Fig. 24. The 
process of Fig. 24 constitutes a ripping process per- 
5 formed by the user who reproduces data from a CD and 
stores the reproduced data into the storage unit 28. 
[0149] In step S171, the CPU 21 of the client 1 first 
acquires data reproduced from the CD as write data 
through the communication unit 29. In step S172, the 
10 CPU 21 determines whether or not the write data ac- 
quired in step S171 contain a watermark. The water- 
mark, made up of three-bit copy control information 
(CCI) and one-bit trigger data, is embedded in the con- 
tent data. If the watermark is detected, the CPU 21 goes 
15 to step S1 73 to extract the watermark from the content. 
If no watermark is detected, step S173 is skipped. 
[0150] In step S174, the CPU 21 prepares header da- 
ta to be recorded in correspondence with the content. 
The header data is composed of a content ID, a license 
20 ID, the URL of the location to be accessed for acquisition 
of the license, and copy control information (CCI) along 
with trigger data included in the watermark. 
[0151] In step S175, the CPU 21, using the client's 
private key, prepares a digital signature based on the 
25 header data generated in step S174. The private key 
has been acquired earlier from the license server 4 (in 
step S67 of Fig. 7). 

[0152] In step S176, the CPU 21 causes the encryp- 
tion/decryption unit 24 to encrypt the content using a 
30 content key. The content key is generated illustratively 
through random number generation. 
[0153] In step S177, the CPU 21 writes the data illus- 
tratively to the magneto-optical disc 43 such as a Mini- 
disc in accordance with a suitable file format. 
35 [0154] Where the storage medium is a Mini-disc, the 
CPU 21 in step S1 76 feeds the content to the codec unit 
25 to encode the content based on ATRAC3. The en- 
coded data are further encrypted by the encryption/de- 
cryption unit 24. 
^0 [0155] Fig. 25 schematically shows how a content is 
written to a storage medium in the manner described 
above. 

[0156] A watermark (WM) is extracted from an en- 
crypted content E(At3) and written outside the content 
45 (i.e., in the header). 

[0157] Fig. 26 illustrates a more detailed file format in 
which to record the content to the storage medium. In 
the format of Fig. 26, a header made up of a content ID 
(CID), a license ID (LID), a URL, and a watermark (WM) 
50 is recorded together with an EKB, data Enc(KR, Kc) pre- 
pared by encrypting a content key Kc using a root key 
KR, a certificate(Cert), a digital signature Sig(Header) 
derived from the header, data Enc(Kc, Content) gener- 
ated by encrypting the content using the content key Kc 
55 meta data, and a mark. 

[01 58] The watermark, usually embedded in the con- 
tent, may be taken out of the content and placed into the 
header as shown in Figs. 25 and 26. Such an outside- 
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content watermark arrangement permits easy and quick 
detection of the information embedded in the content as 
the watermark, so that a check can be made rapidly to 
determine whether or not the content in question is al- 
lowed to be copied. 

[01 59] The meta data represent such data as a jacket, 
photos, and lyrics regarding the content. The meta data 
will be described later in more detail with reference to 
Fig. 32. 

[0160] Fig. 27 schematically shows a typical public 
key certificate. The public key certificate is usually is- 
sued by the certificate authority (CA) of a public key 
cryptosystem. Illustratively, in order to prepare a public 
key certificate, the certificate authority supplements the 
user ID and public key submitted by the user with an 
expiration date and other information as well as a digital 
signature affixed by the authority. According to this in- 
vention, the license server 4 (or the content server 3) 
issues a certificate and a private key (thus a public key 
as well) to the user. In turn, the user submits his or her 
user ID and password to the license server 4 for regis- 
tration, whereby the public key certificate is acquired. 
[0161] The public key certificate in Fig. 27 has a mes- 
sage including a version number of the certificate, a cer- 
tificate serial number assigned by the license server 4 
to the certificate user, an algorithm and parameters used 
for a digital signature, the name of the certificate author- 
ity (license server 4), an expiration date of the certificate, 
the ID of the certificate user (node ID or leaf ID), and a 
public key of the certificate user. The message is sup- 
plemented with the digital signature prepared by the li- 
cense server 4 acting as the certificate authority. The 
digital signature is made of data generated by use of the 
private key of the license server 4 on the basis of a hash 
value generated by applying a hash function to the mes- 
sage. 

[0162] In the example of Fig. 12, the device 0 is as- 
signed a node ID or a lead ID of "0000"; the device 1, 
the ID of "0001"; and the device 15, the ID of "1111." 
Such IDs determine where each device (i.e., entity) is 
positioned (as a leaf or a node) in the tree structure. 
[0163] Where the license for granting the use of each 
content is distributed independent of the content in 
question, the content can be distributed unrestrainedly. 
All contents acquired in any manner or through any 
channels may then be handled in unified fashion. 
[01 64] If the file format is constituted as shown in Fig. 
26, the copyright of each content in that format can be 
properly controlled not only when the content is distrib- 
uted over the Internet but also when the content is of- 
fered to SDMI (Secure Digital Music Initiative) appara- 
tuses. 

[0165] Furthermore, if the content is distributed on a 
storage medium or over the Internet 2 as shown in Fig. 
28, the content can be checked out to a portable device 
(PD) as an SDMI apparatus by resorting to the process 
explained above. 

[0166] Described below with reference to the flow- 



chart of Fig. 29 is how the client 1 checks out a content 
to another client (e.g., PD). 

[0167] In step S191, the CPU 21 judges whether or 
not a digital signature is affixed to the content. If the dig- 
5 ital signal is judged affixed, step S1 92 is reached. In step 
S1 92, the CPU 21 extracts a certificate from the content 
and authenticates it using a public key of the certificate 
authority (i.e., license server 4). More specifically, the 
client 1 acquires from the license server 4 a public key 
10 paired with the private key of the license server 4 and 
decrypts the digital signature affixed to the public key 
certificate by use of the acquired public key. As de- 
scribed above with reference to Fig. 27, the digital sig- 
nature is prepared based on the private key of the cer- 
ts tificate authority (license server 4) and thus can be de- 
crypted using the public key of the license server 4. The 
CPU 21 further computes a hash value by applying a 
hash function to the whole message in the certificate. 
The CPU 21 compares the computed hash value with a 
20 hash value obtained by decrypting the digital signature. 
If the two values match, the message is judged to be 
free of tampering. If the two hash values differ upon 
comparison, the certificate is judged to have been tam- 
pered with. 

25 [0168] In step S1 93, the CPU 21 checks to see wheth- 
er or not the certificate has been tampered with. If the 
certificate is judged to be free of tampering, step S194 
is reached in which the certificate is authenticated using 
the EKB. The authenticating process is carried out by 

30 determining whether or not it is possible to effect trace 
through the EKB based on the leaf ID included in the 
certificate (Fig. 27). How the authenticating process is 
performed will now be described with reference to Figs. 
30 and 31 . 

35 [0169] Suppose now that a device having a leaf key 
K1001 is a revoked device as shown in Fig. 30. In that 
case, an EKB having data (encryption keys) and tags 
shown in Fig. 31 is distributed to each device (leaf). The 
EKB is arranged so as to renew keys KR, K1 K10 and 

40 K100 for revoking the device 1001 in Fig. 30. 

[01 70] All leaves except the revoked device 1 001 can 
acquire a renewed root key K(t)R. That is, since the 
leaves below a node key K0 each retain the unrenewed 
node key K0 within the device, each of these leaves can 

45 obtain a renewed root key K(t)R by decrypting an en- 
cryption key Enc(K0, K(t)R) using the key K0. 
[0171] The leaves below a node 11 may each acquire 
a renewed node key K(t)1 by decrypting an encryption 
key Enc(K11, K(t)1) using a node key K11 yet to be re- 

50 newed. Furthermore, an updated root key K(t)R may be 
obtained by decrypting an encryption key Enc(K(t)1, K 
(t)R) using the node key K(t)1 . The leaves below a node 
key K101 may likewise obtain the renewed root key K 
(t)R. 

55 [0172] A device 1000 having an unrevoked leaf key 
K1000 may acquire a node key K(t)100 by decrypting 
an encryption key Enc(K1000, K(t)100) using its own 
leaf key K1000. The node key K(t)100 thus acquired is 
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then used successively to decrypt node keys at higher 
levels until the renewed root key K(t)R is obtained. 
[0173] On the other hand, the revoked device 1 001 is 
incapable of acquiring the renewed node key K(t)100 
one level higher through the EKB process. That means 
the renewed root key K(t)R cannot be obtained. 
[0174] The valid (i.e., unrevoked) device (client 1) is 
furnished with the EKB containing the data and tags 
shown in Fig. 31. The EKB is distributed by the license 
server 4 to each device for storage therein. 
[01 75] Each client may carry out an EKB tracing proc- 
ess using the furnished tags. The process involves de- 
termining whether or not the key distribution tree may 
be traced starting from the topmost root key. 
[01 76] Illustratively, the leaf ID "1 001 " of the leaf 1 001 
in Rg. 30 may be regarded as four-bit data (1, 0, 0, 1) 
A check is then made to see if the tree structure can be 
traced starting from the most significant bit A "1" bit is 
interpreted to indicate a rightward advance and a "0" bit 
a leftward advance. 

[0177] Because the most significant bit of the ID 
"1001- is "I," the trace advances right from the root key 
KR in Fig. 30. The first tag (numbered 0) in the EKB is 
defined as 0: {0, 0}, interpreted to indicate the presence 
of data on both branches. Since the rightward advance 
is in effect in this case, the node key K1 is reached. 
[0178] The trace now goes to a node below the node 
key K1 The second bit in the ID "1001" is 0, indicating 
a leftward advance. The tag numbered 1 denotes the 
presence or absence of data below the node key K0 to 
the left, and the tag numbered 2 represents the pres- 
ence or absence of data below the node key K1 The 
latter tag is formulated as 2: {0, 0} as shown in Fig. 31 
interpreted to indicate the presence of data on both 
branches. In this case the advance is in the leftward di- 
rection, and the node key K10 is reached. 
[0179] The third bit in the ID "1001" is 0 denoting a 
leftward advance. The tag numbered 3 indicates the 
presence or absence of data below the node key K10 
Formulated as 3: {0, 0}, this tag indicates the presence 
of data on both branches. The advance is to the left and 
the node key K100 is reached. 

[0180] The least significant bit in the ID "1001 ' is "1 " 
indicative of a rightward advance. The tag numbered 4 
corresponds to the node key K1 1 , and the tag numbered 
5 denotes the sign of data under the node key K100 
The latter tag is defined as 5: {0, 1} interpreted to indi^ 
cate the absence of data to the right. That means the 
node 1001 cannot be reached. As a result, the device 
with the ID "1001 - is judged as a revoked device, i.e., a 
device that is banned from acquiring any renewed root 
key through the EKB. 

[0181] Meanwhile, a device with, say, the leaf key 
K1000 has the device ID of "1000.- When the EKG trac- 
ing process is carried out using the tags in the EKB as 
described above, the node '1 000" can be reached. This 
allows the device with the ID "1000" to be judged as a 
valid device. 



[0182] Returning to Fig. 29, the CPU 21 in step S1 95 
determines whether or not the certificate has been re- 
voked based on the result of the authenticating process 
in step S194. If the certificate is not judged to be re- 
5 voked, step S196 is reached. In step S196, the digital 
signature is authenticated using the public key con- 
tained in the certificate. 

[01 83] As shown in Fig. 27, the certificate contains the 
public key of the certificate user (i.e., content provider) 
10 This public key is utilized in authenticating the signature 
(in the header) shown in Fig. 26. More specifically, the 
public key is used to decrypt the digital signature Sig 
(Header) so as to obtain data (i.e., a hash value) for 
comparison with a hash value computed by applying a 
15 hash function to the header in Fig. 26. If the two hash 
values match, it means the header has not been tam- 
pered with. If the two hash values differ, that means the 
header has been tampered with. 
[0184] In step S197, the CPU 21 determines whether 
20 or not the header has been tampered with. If no tamper- 
ing is detected, step S198 is reached in which the wa- 
termark is authenticated. In step S199, the CPU 21 de- 
termines whether or not the result of watermark authen- 
tication justifies a check-out process. If the check-out 
25 process is judged to be allowed, then step S200 is 
reached in which the CPU 21 checks out the content 
Specifically, the CPU 21 transfers the content to the cli- 
ent 1 of the check-out destination for copying. 
[0185] Step S201 is reached for error handling and 
30 check-out is inhibited in any one of the following cases: 
if no digital signature is judged to exist in step S191 ; if 
the certificate is judged to have been tampered with in 
step S193; if the certificate cannot be authenticated in 
step S195 based on the EKB; if the result of digital sig- 
35 nature authentication in step S 1 97 has revealed that the 
header has been tampered with; or if the watermark is 
interpreted to require suppression of check-out in step 
S199. r 

[0186] As described, the license server 4 distributes 
« a certificate and a private key to each user. Upon pre- 
paring a content, the user affixes a digital signature to 
the content to attest its integrity, whereby illegal distri- 
bution of the content is inhibited. 
[01 87] The watermark is extracted during preparation 
45 of the content and the watermark information is added 
to the digital signature. This protects the watermark in- 
formation against tampering and ensures the integrity 
of the content. 

[0188] Each content, once prepared, is thus ensured 
so m its integrity regardless of the manner in which the con- 
tent is distributed. 

[0189] Since the use conditions are attached not to 
each content but to the license for granting the use of 
that content, the use conditions for all contents associ- 
55 ated with a given license may be changed collectively 
as needed by simply changing the use conditions of the 
license in question. 

[01 90] How a mark is used will now be explained. As 
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described above, use conditions are added not to con- 
tents but to licenses. It might happen that contents rel- 
ative to a given license are subject to individually differ- 
ent usages. This state of affairs is dealt with by adding 
marks to the contents under a given license according 
to the invention. 

[0191] Because one license is matched with a plural- 
ity of contents, it is difficult to specify individual usages 
of the contents solely in the use conditions of the corre- 
sponding license. In such cases, the use conditions are 
attached to individual contents for additional manage- 
ment purposes apart from the licenses. 
[0192] As shown in Fig. 32, the mark may illustratively 
have a user ID (leaf ID), an ownership flag, a use start 
time, and a copy count described therein. 
[0193] The mark is also supplemented with a digital 
signature based on the leaf ID, ownership flag, use start 
time, copy count and the like constituting a message. 
[0194] The ownership flag is added if the license for 
grating a limited-time use of the content is replaced by 
an outright purchase of the license (i.e., for permanent 
usage). The use start time is described if the content 
has started to be used within a specific time period. Il- 
lustratively, if the time period in which to download the 
content is limited, the use start time described here in- 
dicates the actual date and time at which the content is 
downloaded within that period. This is to certify that the 
content is used legitimately within the designated peri- 
od. 

[0195] The copy count is a log describing the number 
of times the content in question has been copied so far. 
[0196] Described below with reference to the flow- 
chart of Fig. 33 is how a mark is added to a content when 
the user purchases the license for that content. 
[01 97] In step S221 , the CPU 21 first gains access to 
the license server 4 over the Internet 2 in response to a 
command entered by the user into the input unit 26. 
[0198] In step S222, the CPU 21 acquires the com- 
mand input from the user through the input unit 26. In 
accordance with the command, the CPU 21 requests an 
outright purchase of the license from the license server 
4. 

[0199] Upon receipt of the request, the license server 
4 proposes a price for the license, as will be described 
later with reference to the flowchart of Fig. 34 (in step 
S242 of Fig. 34). In step S223, the CPU 21 of the client 
1 receives the proposed price from the license server 4 
and causes the output unit 27 to display the price. 
[0200] Upon viewing the display, the user decides 
whether or not to accept the proposed price. The user 
enters the result of his or her decision into the input unit 
26. 

[0201] In step S224, the CPU 21 receives the user's 
input through the input unit 26 and judges whether or 
not the user has accepted the proposed price. If the pro- 
posed price is judged accepted, the CPU 21 goes to step 
S225 and reports the acceptance to the license server4. 
[0202] Given the report of the acceptance, the license 



server 4 returns a mark that has an ownership flag, i.e., 
information denoting the outright purchase of the license 
at the proposed price, described therein (in step S244 
of Fig. 34). In step S226, the CPU 21 of the client 1 re- 

5 ceives the mark from the license server 4. In step S227, 
the CPU 21 embeds the received mark into the content. 
This causes the mark including the ownership flag of 
Fig. 32 to be recorded as a mark of content relative to 
the purchased license in correspondence with the con- 

io tent. With the message thus renewed, the CPU 21 also 
renews the digital signature (Fig. 26) and writes the re- 
newed signature to the storage medium. 
[0203] If in step S224 the price proposed by the li- 
cense server 4 is not judged accepted, step S228 is 

is reached. In step S228, the CPU 21 reports rejection of 
the proposed price to the license server 4. 
[0204] In conjunction with the above-described proc- 
ess of the client 1, the license server 4 carries out the 
steps in the flowchart of Fig. 34. 

20 [0205] In step S241 , the CPU 21 of the license server 
4 first receives a license purchase request from the cli- 
ent 1 (in step S222 of Fig. 33). Upon receipt of the re- 
quest, the CPU 21 goes to step S242 to retrieve from 
the storage unit 28 the price for the outright purchase of 

25 the license in question, and transmits the price to the 
client 1. 

[0206] As described above, the client 1 reports either 
the acceptance or the rejection of the proposed price. 
[0207] In step S243, the CPU 21 of the license server 

30 4 judges whether or not the report of the acceptance is 
received from the client 1 . If the acceptance report is 
judged received, then step S244 is reached. In step 
S244, the CPU 21 of the license server 4 generates a 
mark that contains a message specifying the purchase 

35 of the license in question, affixes a digital signature to 
the mark using its own private key, and transmits the 
mark to the client 1 . The mark thus transmitted is written 
to the applicable content in the storage unit 28 of the 
client 1 as described above (in step S227 of Fig. 33). 

40 [0208] If in step S243 the acceptance report is not 
judged received from the client 1, then step S244 is 
skipped. In this case, the purchase of the license is not 
accomplished, so that the mark will not be transmitted. 
[0209] Fig. 35 shows a typical structure of a mark 

45 transmitted from the license server 4 to the client 1 . In 
this example, the mark is made up of the user's leaf ID 
and his or her ownership flag (Own) and of a digital sig- 
nature Sigs(LeaflD, Own) generated using a private key 
S of the license server 4 on the basis of the leaf ID and 

50 ownership flag. 

[0210] The mark is valid only for a specific content of 
a particular user. If the content in question is copied, the 
mark accompanying the copied content is invalidated. 
[0211] As described, each content and its license are 

55 handled independently of one another, and the use con- 
ditions are associated with each license. This scheme 
makes it possible to offer diverse services reflecting the 
different use status of individual contents. 



17 



33 



EP 1 282 262 A1 



34 



[0212] Described below is what is known as grouping 
Grouping involves putting together a plurality of devices 
or storage media to form a group within which a content 
may be exchanged freely. Grouping usually applies to 
devices or storage media owned by an individual 
Whereas the devices or storage media forming a single 
group were conventionally assigned a group key for 
control purposes, the target devices or storage media 
to be grouped may be associated with a single license 
for easier grouping control according to the invention. 
[021 3] It is also possible to register beforehand each 
of the devices forming a given group for the same control 
purpose. Typical grouping with devices registered in ad- 
vance will now be described. 

[0214] In this example, the user needs to register be- 
forehand with the server the certificates of the devices 
to be grouped. The certificates are registered in the 
steps of the flowcharts in Figs. 36 and 37. 
[0215] Referring first to Fig. 36, the client (one of the 
devices to be grouped) has its certificate registered as 
follows: in step S261, the CPU 21 of the client 1 which 
is subjected to grouping prepares its own certificate con- 
taining its public key. 

[0216] In step S262, the CPU 21 gains access to the 
content server 3 based on the user's input through the 
input unit 26. In step S263, the certificate prepared in 
step S261 is transmitted to the content server 3. 
[0217] Alternatively, the certificate received from the 
license server 4 may be used unmodified for the regis- 
tration. * 

[021 8] The steps above are carried out by all devices 
that constitute the group in question. 
[0219] Described below with reference to the flow- 
chart of Fig. 37 is .how the content server 3 performs a 
certificate registering process in conjunction with the 
registering process carried out by the client 1 as shown 
m Fig. 36. In step S271 , the CPU 21 of the content server 
3 receives the certificate from the client 1 . In step S272 
the CPU 21 stores the received certificate into the stor- 
age unit 28. 

[0220] The steps above are carried out regarding 
each of the devices constituting the group in question 
As a result, the storage unit 28 of the content server 3 
has the certificates of the devices registered in units of 
groups, as illustrated in Fig. 38. 

[0221] In the example of Fig. 38, a group 1 is matched 
with certificates C11 through C14 being registered The 
certificates C11 through C14 contain corresponding 
public keys K P11 through K P14 respectively. 
[0222] Likewise, certificates C21 through C23 are 
registered in association with a group 2. The certificates 
C21 through C23 include corresponding public keys 
K P21 through K P23 respectively. 
[0223] In the manner described, the devices consti- 
tuting each of the groups above have their certificates 
registered in advance. It might happen that a user pos- 
sessing a group of devices requests the content server 
3 to provide a content to the grouped devices. In that 



case, the content server 3 carries out the steps in the 
flowchart of Fig. 39. 

[0224] In step S281 , the CPU 21 of the content server 
3 first authenticates the certificates belonging to the 
5 group in question from among the certificates held in the 
storage unit 28. 

[0225] The authenticating process of step S281 is car- 
ried out as described above with reference to Figs. 30 
and 31, by tracing EKBs using tags based on the leaf 
10 IDs included in the certificates of the devices involved. 
The EKBs are also distributed to the content server 3 
from the license server 4. The authenticating process 
rules out any certificate that has been revoked 
[0226] In step S282, the CPU 21 of the content server 
w 3 selects the certificates found valid following the au- 
thenticating process of step S281. In step S283, the 
CPU 21 encrypts the content key using those certifi- 
cates of the devices which were selected in step S282 
In step S284, the CPU 21 transmits to the grouped de- 
20 vices the content together with the content key encrypt- 
ed in step S283. 

[0227] Suppose now that in the group 1 of Fig. 38, the 
certificate C14 is found revoked. In such a case ' the 
process of step S283 generates encrypted data shown 
25 in Fig. 40. 

[0228] In the example of Fig. 40, the content key Kc 
is shown encrypted using the public key K P11 of the cer- 
tificate C11, public key K P12 of the certificate C12 or 
public key K P13 of the certificate C13. 
30 [0229] In conjunction with the process of Fig. 39 car- 
ried out by the content server 3, each of the grouped 
devices (i.e., clients) receiving the content performs the 
steps shown in the flowchart of Fig. 41. 
[0230] In step S291, the CPU 21 of the client 1 re- 
35 ceives the content together with the content key follow- 
ing its transmission from the content server 3 in step 
S284 of Fig. 39. The content has been encrypted by use 
of the content key Kc which in turn has been encrypted 
by the public key retained by each of the devices in- 
volved (Fig. 40). 

[0231] In step S292, the CPU 21 using its own private 
key decrypts and acquires the content key addressed 
to the client, the self-addressed content key having been 
received in step S291 . The acquired content key is then 
45 used to decrypt the content. 

[0232] Illustratively, the device corresponding to the 
certificate C11 shown in Fig. 40 decrypts and acquires 
the content key Kc using its private key paired with the 
public key K P11 . The content key Kc is then utilized in 
50 decrypting the content. 

[0233] The above-described, steps are also carried 
out by the devices corresponding to the certificates C12 
and C13. The device corresponding to the revoked cer- 
tificate C14 does not receive along with the content a 
55 content key Kc that would have been encrypted by use 
of the public key specific to the device in question That 
means the device is incapable of acquiring the content 
using the content key Kc. 
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[0234] in the foregoing description, devices are 
shown grouped with respect to the content key (i.e., con- 
tent). Alternatively, devices may be grouped with regard 
to a license key (i.e., license). 

[0235] In the manner described, multiple devices may 
be grouped for control purposes without recourse to a 
special group key or to an ICV (integrity check value), 
to be described later. The grouping procedure above is 
best suited for grouping a small number of devices. 
[0236] According to this invention, it is also possible 
to checked out, check in, move or copy licenses. These 
processes are carried out under rules stipulated by SD- 
MI. 

[0237] How a license is checked out by a client will 
now be described by referring to the flowcharts of Figs. 
42 and 43. 

[0238] Described first are the steps in which the client 
checks out a license to another client, as shown in Fig. 
42. In step S301, the CPU 21 of the client 1 reads a 
check-out count N1 of the license to be checked out. 
The check-out count is retrieved from the use conditions 
such as those shown in Fig. 8. 

[0239] In step S302, the CPU 21 reads a maximum 
check-out count N2 of the license to be checked out. 
The maximum check-out count is also retrieved from the 
use conditions of the license. 

[0240] In step S303, the CPU 21 compares the check- 
out count N1 retrieved in step S301 with the maximum 
check-out count N2 read in step S302. A check is made 
to see if the check-out count N1 is smaller than the max- 
imum check-out count N2. 

[0241] If the check-out count N1 is judged smaller 
than the maximum check-out count N2, step S304 is 
reached. In step S304, the CPU 21 acquires the leaf key 
of the other client (i.e., client of the check-out destina- 
tion) and writes the acquired leaf key to a check-out list 
in the storage unit 28 in correspondence with the ID of 
the license to be checked out. 

[0242] In step S305, the CPU 21 increments by 1 the 
check-out count N1 of the license, the count having 
been retrieved in step S301 . In step S306, the CPU 21 
computes an ICV based on the message of the license. 
The ICV will be described later with reference to Figs. 
47 through 51. The ICV scheme is designed to prevent 
the tampering of the licenses. 

[0243] In step S307, the CPU 21 encrypts the license 
in question as well as the ICV computed in step S306 
using the public key of this client, and outputs what is 
encrypted together with an EKB and a certificate to the 
other client for copying. In step S308, the CPU 21 writes 
the ICV computed in step S306 to a check list in the stor- 
age unit 28 in correspondence with the leaf key of the 
other client and the license ID. 

[0244] If in step S303 the check-out count N1 is not 
judged smaller than (e.g., found equal to) the maximum 
check-out count N2, that means the maximum permis- 
sible check-out count has been exhausted so that the 
license can no longer be checked out. In that case, the 
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CPU 21 goes to step S309 for error handling. The check- 
out process will be terminated unaccomplished. 
[0245] Described below with reference to the flow- 
chart of Fig. 43 is how a client has a license checked 

5 out from another client. This process takes place in con- 
junction with the check-out process of Fig. 42. 
[0246] In step S321 , the CPU 21 of the client 1 (of the 
check-out destination) transmits the leaf key of this cli- 
ent to another client (i.e., the license check-out source 

10 client). The leaf key is stored by the other client in cor- 
respondence with the license ID (in step S304). 
[0247] In step S322, the CPU 21 receives from the 
other client 1 the encrypted license and ICV together 
with the EKB and certificate. The license, ICV, EKB, and 

is certificate were transmitted earlier by the other client in 
step S307 of Fig. 42. 

[0248] In step S323, the CPU 21 stores into the stor- 
age unit 28 the license, ICV, EKB, and certificate re- 
ceived in step S322. 
20 [0249] The client 1 has the license checked out there- 
to from the other client in the manner described above. 
Thereafter, the client 1 reproduces the content corre- 
sponding to the checked-out license by carrying out the 
steps in the flowchart of Fig. 44. 
25 [0250] In step S341 , the CPU 21 of the client 1 com- 
putes the ICV of the content designated to be repro- 
duced by the user through the input unit 26. In step 
S342, the CPU 21 decrypts the ICV in the storage unit 
28 based on the public key included in the certificate. 
30 [0251] In step S343, the CPU 21 judges whether or 
not the ICV computed in step S341 matches the ICV that 
was retrieved and decrypted in step S341 . If the two val- 
ues match, it means the license has not been tampered 
with. In that case, the CPU 21 goes to step S344 to re- 
35 produce the applicable content. 

[0252] If in step S343 the two ICVs fail to match, that 
means the license may have been tampered with. In 
such a case, the CPU 21 goes to step S345 for error 
handling. Here, the content cannot be reproduced by 
40 use of the license in question. 

[0253] Described below with reference to the flow- 
chart of Fig. 45 is how a client has a previously checked- 
out license checked in from another client. 
[0254] In step S361 , the CPU 21 first acquires the leaf 
45 key of the other client (i.e., the client about to check in 
the license) and the ID of the license to be checked in. 
In step S362, the CPU 21 judges whether or not the tar- 
get license whose ID was acquired in step S361 is a 
license previously checked out from this client to the oth- 
50 er client. The judgment is made based on the ICV, leaf 
key and license ID stored in step S308 of Fig. 42. More 
specifically, a check is made to see whether or not the 
leaf key, license ID and ICV acquired in step S361 are 
held in the check-out list. If the leaf key, license ID and 
55 ICV are judged retained in the check-put list, that means 
the license in question has indeed been checked out by 
this client to the other client. 

[0255] If the result of the check in step S362 is affirm- 
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at.ve, then the CPU 21 goes to step S363 requesting 
the other client to delete the license, EKB and certificate 
involved. Given the request, the other client deletes the 
license, EKB and certificate as will be described later (in 
step S383 of Fig. 46). 

[0256] In step S364, the CPU 21 decrements by 1 the 
check-out count N1 of the license in question. This is 
done to reflect the fact that a previously checked-out li- 
cense is now returned (i.e., checked in). 
[0257] In step S365, the CPU 21 determines whether 
or not this client has any other license still checked out 
to the other client. If there is no such license, step S366 
is reached in which the CPU 21 deletes from the check- 
out list the record of the other client as a possible client 
for subsequent check-in. If In step S365 any other li- 
cense is judged still checked out to the other client, the 
other client may subsequently request another check-in 
session and thus step S366 is skipped. 
[0258] If in step S362 the license in question is not 
judged to be one previously checked out to the other 
client, then the CPU 21 goes to step S367 for error han- 
dling. In this case, the license in question is not subject 
to control by this client and the check-in process will not 
take place. 

[0259] If the user, has illegally copied the license the 
stored ICV becomes different from the ICV computed 
on the basis of the license acquired in step S361 . In that 
case, the check-in process will end unaccomplished. 
[0260] Fig. 46 shows steps performed by a client hav- 
ing its license checked in to another client. This process 
takes place in conjunction with the license check-in 
process shown in the flowchart of Fig. 45. 
[0261] In step S381 , the CPU 21 of the client 1 trans- 
mits to another client (i.e., client 1 carrying out the steps 
in the flowchart of Fig. 45) the leaf key of this client 1 
and the ID of the license to be checked in. As described 
above, the other client acquired earlier the leaf key and 
license ID in step S361 and authenticated the license to 
be checked in based on the acquired leaf key and li- 
cense ID in step S362. 

[0262] In step S382, the CPU 21 of this client 1 judges 
whether or not the other client has requested deletion 
of the license. That is, if the license is a legitimate li- 
cense that can be checked in, the other client requests 
deletion of the license, EKB and certificate involved in 
step S363 as described above. Upon receipt of that re- 
quest, the CPU 21 reaches step S383 to delete the li- 
cense, EKB and certificate. Following step S383, the 
other client can no longer make use of the license in 
question. The check-out count N1 of the license is then 
decremented by 1 in step S364 and the check-in proc- 
ess is accomplished. 

[0263] If in step S382 the other client is not judged to 
request the deletion of the license, then the CPU 21 
goes to step S384 for error handling. The check-in proc- 
ess remains unaccomplished due to a mismatch of the 
ICVs involved. 

[0264] In the same manner in which the check-in and 



check-out processes are carried out as described 
above, licenses can also be copied or moved from one 
client to another. 

[0265] What follows is a description of how an integrity 
5 check value (ICV) is generated for each license, how 
the ICV is brought into correspondence with the license, 
and how the ICV is computed to determine whether or 
not the license in question has been tampered with. The 
same process applies to prevention of tampering with 
™ regard to both licenses and contents. 

[0266] The ICV (integrity check value) for a given li- 
cense is computed illustratively by having a hash func- 
tion applied to that license as 
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ICV = hash (Kiev, L1,L2, ...) 



where Kiev stands for an ICV generation key, and L1, 
L2, ... denote license information. A message authenti- 
20 cation code (MAC) for use in ICV generation constitutes 
an important element of the license information. 
[0267] Fig. 47 is an explanatory view showing how a 
message authentication code (MAC) is generated using 
a DES (Data Encryption Standard) arrangement. As 
25 shown in Fig. 47, a message to be encrypted by DES is 
divided into units of eight bytes (the divided units of the 
message are called divided messages M1, M2, .... MN 
hereunder). First, an initial value (IV) and the'divided 
message M1 are exclusively ORed by an arithmetic unit 
30 24-1 A outputting a resulting value of 11 . The value 11 is 
input to a DES encryption unit 24-1 B for an encrypting 
process using a key K1, the unit 24-1 B outputting a re- 
sulting value of E1 . The value E1 and divided message 
M2 are exclusively ORed by an arithmetic unit 24-2A 
35 which outputs a resulting value of 12. The value 12 is in- 
put to a DES encryption unit 24-2B for an encrypting 
process using the key K1, the unit 24-2B outputting a 
resulting value of E2. These steps are repeated to cover 
all divided messages. A value EN ultimately resulting 
from a DES encryption unit 24-NB in the most down- 
stream stage constitutes a message authentication 
code (MAC). 

[0268] A hash function is applied to the MAC thus ac- 
quired and to the ICV generation key for the license 
45 whereby an integrity check value (ICV) of the license is 
generated. Illustratively, if the ICV created upon gener- 
ation of the license is judged to be the same as the ICV 
produced anew based on the license, it guarantees that 
the license has not been tampered with. If the two ICVs 
50 are found to be different upon comparison, that means 
the license has been tampered with. 
[0269] Described below is how the ICV generation 
key Kiev of a given license is typically delivered to de- 
vices using the above-described enabling key block 
55 (EKB). In this case, encrypted message data in the EKB 
are used as the ICV generation key for the license in 
question. 

[0270] Figs. 48 and 49 show examples in which a li- 
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cense common to a plurality of devices is sent to them 
with an enabling key block (EKB) used to deliver the ICV 
generation key Kiev for verifying the integrity of the li- 
cense in question. The example of Fig. 48 involves de- 
livering an ICV generation key Kiev decryptable by de- 
vices 0, 1 , 2 and 3, while the example of Fig. 49 involves 
delivering an ICV generation key Kiev decryptable solely 
by devices 0, 1 and 2 with the device 3 revoked. 
[0271] In the example of Fig. 48, a renewed node key 
K(t)00 is used to encrypt the ICV generation key Kiev, 
giving data Enc(K(t)00, Kiev). The data Enc(K(t)00, 
Kiev) are delivered along with the EKB from which the 
renewed node key K(t)00 may be decrypted by each of 
the devices 0, 1, 2 and 3 using their respective node 
keys and leaf keys. As shown on the right-hand side of 
Fig. 48, each device first decrypts the EKB to acquire 
the renewed node key K(t)00, and decrypts the encrypt- 
ed ICV generation key Enc(K(t)00, Kiev) using the ac- 
quired node key K(t)00 in order to obtain the ICV gen- 
eration key Kiev. 

[0272] The other devices 4, 5, 6, 7, etc., even when 
they receive the same enabling key block (EKB), cannot 
acquire the renewed node key K(t)00 by decrypting the 
received EKB using their own node keys and leaf keys. 
Thus only the legitimate devices alone can receive the 
delivered ICV generation key. 

[0273] In the example of Fig. 49, it is assumed that 
the device 3 in the group enclosed by broken line in Fig. 
12 is revoked because of a leaked key and that the en- 
abling key block (EKB) decryptable only by the devices 
0, 1 and 2 is generated and delivered to them. The EKB 
and the ICV generation key Kiev in Fig. 49 are encrypted 
by the node key K(t)00 to produce encrypted data Enc 
(K(t)00, Kiev) for delivery to the devices involved. 
[0274] Shown on the right-hand side of Fig. 49 are 
steps for decrypting the delivered EKB and encrypted 
data. The devices 0, 1 and 2 first acquire the renewed 
node key K(t)00 by decrypting the received EKB using 
their own leaf keys or node keys. The renewed node key 
K(t)00 thus acquired is then used in a decrypting proc- 
ess to obtain the ICV generation key Kiev. 
[0275] The devices 4, 5, 6, etc., in other groups shown 
in Fig. 12 may receive the same data (i.e., EKB) but are 
incapable of acquiring the renewed node key K(t)00 
from the received data using their own leaf keys or node 
keys. Similarly, the revoked device 3 cannot obtain the 
renewed node key K(t)00 using its own leaf key or node 
key. Only the devices with legitimate rights are capable 
of decrypting the ICV generation value for their use. 
[0276] Where the ICV generation key is delivered by 
use of the EKB as described above, it is possible to im- 
plement a scheme whereby the ICV generation key is 
delivered in a way securely decryptable only by those 
entitled to receive the key with a minimum of data 
amount involved. 

[0277] The use of the integrity check value (ICV) for 
licenses makes it possible to eliminate illegal copy of 
EKBs and encrypted licenses. Illustratively, as shown in 



Fig. 50A, suppose that licenses L1 and L2 are stored on 
a storage medium 1 together with EKBs for allowing the 
licenses to be acquired and that what is stored on the 
storage medium 1 is copied entirely to a storage medium 

5 2. In that case, with the EKBs and licenses copied onto 
the storage medium 2, the copied licenses can be used 
by any device capable of decrypting the EKBs. 
[0278] In the example of Fig. SOB, the licenses held 
legitimately on a given storage medium are furnished 

10 with a corresponding integrity check value ICV(L1 , L2). 
The value ICV(L1, L2) denotes an ICV given as 

ICV = hash (Kiev, L1, L2) 

15 

which is an integrity check value computed by having a 
hash function applied to the licenses L1 and Li2. In the 
example of Fig. 50B, the storage medium 1 legitimately 
contains the licenses L1 and L2 together with the integ- 

20 rity check value ICV(L1 , L2) generated based on the two 
licenses. The storage medium 2 legitimately contains 
the license L1 along with an integrity check value ICV 
(L1) generated based on the license L1. 
[0279] In the case of Fig. 50B, suppose that the EKB 

25 and the license 2 held on the storage medium 1 are cop- 
ied to the storage medium 2 and that a license check 
value is generated anew for the storage medium 2. In 
that case, the integrity check value ICV(L1, L2) is gen- 
erated which differs from Kicv(L1) retained on the stor- 

30 age medium 2. This reveals tampering with or illegal 
copy of the license that has been written to the storage 
medium. A device about to reproduce data from the stor- 
age medium carries out an ICV check before a data- 
reproducing step to determine whether or not there is a 

35 match between the generated ICV and the stored ICV. 
In case of a mismatch, the device will not reproduce data 
from the storage medium. This prevents reproduction of 
any illegally copied license. 

[0280] In order to enhance security further, it is pos- 
40 sible to generate the integrity check value (ICV) for each 
license on the basis of data including a renewal counter. 
More specifically, the ICV is computed as 

ICV = hash(Kicv, counter+1 , L1 , L2, ...) 

45 

where the counter (counter+1) is established as a value 
that is incremented by 1 every time the ICV is renewed. 
The counter value needs to be stored in a secure mem- 
so ory. 

[0281] Where the ICV for a license cannot be held on 
the same storage medium as the license in question, 
that ICV may be held on a storage medium separate 
from that of the license. 
55 [0282] Illustratively, if a license is placed onto a read- 
only medium, an MO, or like storage medium that is not 
copy-protected, then putting the corresponding ICV on 
the same medium may prompt an unscrupulous user il- 
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legally to renew the ICV compromising its integrity. Such 
an eventuality is circumvented by keeping the ICVs on 
a secure storage medium in the host machine so that 
they are retrieved as needed for license copy control (e. 
g., check-in, check-out, move). This scheme provides 5 
securer ICV control measures and more elaborate li- 
cense tampering checks. 

[0283] The scheme above is typically implemented as 
shown in Fig. 51. In the example of Fig. 51, licenses 1, 
2 and 3 are held on a storage medium 2201 such as a io 
read-only medium, an MO or other storage medium that 
is not copy-protected. The ICV regarding these licenses 
is retained on a secure storage medium 2202 in the host 
machine that cannot be accessed freely by users. This 
arrangement prevents dishonest users from illegally re- 15 
newing the integrity check value (ICV). Each device 
loaded with the storage medium 2201 requests the host 
machine such a PC or a server to perform ICV checks 
to determine whether or not data reproduction from the 
loaded storage medium is permitted. This effectively 20 
prevents illegal copying of or tampering with any license. 
[0284] The clients to which this invention applies in- 
clude not only so-called personal computers but also 
PDAs (personal digital assistants), mobile telephones 
and game consoles. 25 
[0285] The series of steps described above may be 
executed either by hardware or by software. For soft- 
ware-based processing to take place, programs consti- 
tuting the software may be either incorporated before- 
hand in dedicated hardware of a computer or installed 30 
upon use over a network or from a suitable program stor- 
age medium into a general-purpose personal computer 
or like equipment capable of executing diverse func- 
tions. 

[0286] As shown in Fig. 2, the program storage medi- 35 
urn is offered to users apart from computers not only as 
a package medium constituted by the magnetic disc 41 
(including floppy discs), optical disc 42 (including 
CD-ROM (compact disc-read only memory) and DVD 
(digital versatile disc)), magneto-optical disc 43 (includ- 40 
ing MD (Mini-disc)), or semiconductor memory 44, each 
containing the necessary programs; but also in the form 
of the ROM 22 or the hard disc in the storage unit 28 
which contains the programs and which are incorporat- 
ed in the computers before being offered to users. 45 
[0287] In this specification, the steps which are stored 
on the program storage medium and which describe the 
programs to be executed represent not only the proc- 
esses that are carried out in the depicted sequence (i. 
e., on a time series basis) but also processes that are so 
conducted parallelly or individually. 
[0288] Any programs implementing security- related 
processes should preferably be encrypted to guard 
against analysis for tampering. Illustratively, the pro- 
grams for carrying out cryptographic processes should ss 
be structured, as tamper- resistant modules. 
[0289] Information placed in the header of a content 
to identify the license for using that content is not limited 



to the license ID for uniquely identifying the license in 
question. In the above-described embodiments, the li- 
cense ID serves as information which specifies the li- 
cense granting the use of a particular content; as infor- 
mation which identifies the content whose use is granted 
by a specific license; and as information which is re- 
quested by a license request from the client 1 for iden- 
tification of a given license. Alternatively, each content 
may include a list of information about various attributes 
of the content in question, and each license may com- 
prise a conditional expression of the content whose use 
is granted by the license in question. In this case, the 
attribute information attached to each content consti- 
tutes information for identifying the license for granting 
the use of the content in question, and the conditional 
expression included in each license serves as informa- 
tion for specifying the content whose use is granted by 
the license in question; the license ID serves as infor- 
mation for uniquely identifying each license. These ar- 
rangements make it possible to assign a plurality of li- 
censes to a single content, thereby providing a flexible 
license issuing scheme. 

[0290] The content data are not limited to music data. 
Contents may be constituted illustratively by image da- 
ta, moving image data, text data, animation data, soft- 
ware programs, or a combination of any of them. 
[0291] In this specification, the term "system" refers 
to an entire configuration made up of a plurality of com- 
ponent devices. 

INDUSTRIAL APPLICABILITY 

[0292] As described above, where the information 
processing apparatus, information processing method, 
and program according to the first, second, and fourth 
aspects of the invention are in use the inventive appa- 
ratus can manage keys depending on the different pro- 
vision categories. 

[0293] As described above, where the information 
processing apparatus, information processing method, 
and program according to the fifth, sixth, and eighth as- 
pects of the invention are in use, the inventive apparatus 
can manage keys depending on the different provision 
categories. 

[0294] Where the information processing apparatus, 
information processing method, and program according 
to the ninth, tenth, and twelfth aspects of the invention 
are in use, the inventive apparatus can make use of a 
plurality of contents belonging to different provision cat- 
egories. 

[0295] Where the information processing apparatus, 
information processing method, and program according 
to the thirteenth, fourteenth, and sixteenth aspects of 
the invention are in use, the inventive apparatus can 
store a plurality of different device node key. 
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Claims 



1. An information processing apparatus for providing 
a device node key used to decrypt an enabling key 
block included in a content, said information 
processing apparatus comprising: 

assigning means which, in a key-managed hi- 
erarchical tree structure having a content pro- 
vision category assigned to a first node on a 
given level of the structure, assigns uniquely a 
second information processing apparatus to a 
leaf subordinate to said first node; and 
providing means for providing said second in- 
formation processing apparatus with said de- 
vice node key corresponding to a path between 
said leaf assigned by said assigning means and 
said first node. 

2. The information processing apparatus according to 
claim 1 , wherein said providing means further pro- 
vides said second information processing appara- 
tus with leaf identification information for identifying 
said leaf, in addition to said device node key. 

3. The information processing apparatus according to 
claim 2, further comprising receiving means for re- 
ceiving from said second information processing 
apparatus a license request including both said leaf 
identification information and license identification 
information for identifying a license granting the use 
of said content; and 

transmitting means for transmitting said li- 
cense which is added said leaf identification infor- 
mation included in said license request and which 
comprises a digital signature. 

4. An information processing apparatus according to 
claim 1 , wherein said providing means further pro- 
vides said second information processing appara- 
tus with a private key and a public key of said sec- 
ond information processing apparatus as well as a 
public key of said information processing appara- 
tus, in addition to said device node key. 

5. An information processing method for use with an 
information processing apparatus for providing a 
device node key used to decrypt an enabling key 
block included in a content, said information 
processing method comprising the steps of: 

assigning uniquely a second information 
processing apparatus to a leaf subordinate to 
said first node in a key-managed hierarchical 
tree structure having a content provision cate- 
gory assigned to a first node on a given level of 
the structure; and 

providing said second information processing 



apparatus with said device node key corre- 
sponding to a path between said leaf assigned 
in said assigning step and said first node. 

5 6. A storage medium which stores a computer-reada- 
ble program for use with an information processing 
apparatus for providing a device node key used to 
decrypt an enabling key block included in a content, 
the program comprising the steps of: 

10 

assigning uniquely a second information 
processing apparatus to a leaf subordinate to 
said first node in a key-managed hierarchical 
tree structure having a content provision cate- 
15 gory assigned to a first node on a given level of 

the structure; and 

providing said second information processing 
apparatus with said device node key corre- 
sponding to a path between said leaf assigned 
20 in said assigning step and said first node. 

7. A program executable by a computer for controlling 
an information processing apparatus for providing 
a device node key used to decrypt an enabling key 

25 block included in a content, said program causing 
said computer to carry out the steps of: 

assigning uniquely a second information 
processing apparatus to a leaf subordinate to 
30 said first node in a key-managed hierarchical 

tree structure having a content provision cate- 
gory assigned to a first node on a given level of 
the structure; and 

providing said second information processing 
35 apparatus with said device node key corre- 

sponding to a path between said leaf assigned 
in said assigning step and said first node. 

8. An information processing apparatus for providing 
40 a license granting the use of a content, said infor- 
mation processing apparatus comprising: 

receiving means for receiving from a second in- 
formation processing apparatus leaf identifica- 
45 tion information for identifying in a key-man- 

aged hierarchical tree structure a leaf assigned 
to said second information processing appara- 
tus; and 

transmitting means which, if said leaf identifica- 
50 tion information received by said receiving 

means identifies a leaf subordinate to a first 
node on a given level of the structure, said first 
node being assigned a content provision cate- 
gory, then transmits said license including said 
55 leaf identification information to said second in- 

formation processing apparatus. 

9. An information processing method for use with an 
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information processing apparatus for providing a li- 
cense granting the use of a content, said informa- 
tion processing method comprising the steps of: 

receiving from a second information processing 
apparatus leaf identification information for 
identifying in a key-managed hierarchical tree 
structure a leaf assigned to said second infor- 
mation processing apparatus; and 
transmitting said license including said leaf 
identification information to said second infor- 
mation processing apparatus if said leaf identi- 
fication information received in said receiving 
step identifies a leaf subordinate to a first node 
on a given level of the structure, said first node 
being assigned a content provision category. 

10. A storage medium which stores a computer-reada- 
ble program for use with an information processing 
apparatus for providing a license granting the use 
of a content, the program comprising the steps of: 

receiving from a second information processing 
apparatus leaf identification information for 
identifying in a key-managed hierarchical tree 
structure a leaf assigned to said second infor- 
mation processing apparatus; and 
transmitting said license including said leaf 
identification information to said second infor- 
mation processing apparatus if said leaf identi- 
fication information received in said receiving 
step identifies a leaf subordinate to a first node 
on a given level of the structure, said first node 
being assigned a content provision category. 

11. A program executable by a computer for controlling 
an information processing apparatus for providing 
a license granting the use of a content, said pro- 
gram causing said computer to carry out the steps 
of: 
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including content identification information for 
identifying a content; and 
transmitting means for transmitting an encrypt- 
ed content including an enabling key block de- 
cryptable by use of a device node key corre- 
sponding to a path between a leaf subordinate 
to a first node on a given level of a key-man- 
aged hierarchical tree structure, and said first 
node which is assigned a content provision cat- 
egory. 

13. An information processing method for providing 
contents, comprising the steps of: 

receiving a content request including content 
identification information for identifying a con- 
tent; and 

transmitting an encrypted content including an 
enabling key block decryptable by use of a de- 
vice node key corresponding to a path between 
a leaf subordinate to a first node on a given lev- 
el of a key-managed hierarchical tree structure, 
and said first node which is assigned a content 
provision category. 

14. A storage medium which stores a computer-reada- 
ble program for use with an information processing 
apparatus for providing contents, the program com- 
prising the steps of: 

receiving a content request including content 
identification information for identifying a con- 
tent; and 

transmitting an encrypted content including an 
enabling key block decryptable by use of a de- 
vice node key corresponding to a path between 
a leaf subordinate to a first node on a given lev- 
el of a key-managed hierarchical tree structure, 
and said first node which is assigned a content 
provision category. 



receiving from a second information processing 
apparatus leaf identification information for 
identifying in a key-managed hierarchical tree 
structure a leaf assigned to said second infor- 
mation processing apparatus; and 
transmitting said license including said leaf 
identification information to said second infor- 
mation processing apparatus if said leaf identi- 
fication information received in said receiving 
step identifies a leaf subordinate to a first node 
on a given level of the structure, said first node 
being assigned a content provision category. 

12. An information processing apparatus for offering 
contents, comprising: 



15. A program executable by a computer for controlling 
an information processing apparatus for providing 
contents, said program causing said computer to 
4 5 carry out the steps of: 



receiving a content request including content 
identification information for identifying a con- 
tent; and 

transmitting an encrypted content including an 
enabling key block decryptable by use of a de- 
vice node key corresponding to a path between 
a leaf subordinate to a first node on a given lev- 
el of a key-managed hierarchical tree structure, 
and said first node which is assigned a content 
provision category. 
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receivingmeansforreceivingacontentreques, 16. An intonation processing apparatus for outputting 
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contents, comprising: 

storing means for storing a device node key 
corresponding to an extent between a leaf 
which is assigned to said information process- 5 
ing apparatus and which is subordinate to a first 
node on a given level of a key-managed hier- 
archical tree structure, and said first node 
which is assigned a content provision category; 
content acquiring means for acquiring an en- 1 <> 
crypted content including an enabling key block 
for associating said first node with a root key; 
decrypting means for decrypting said encrypt- 
ed content by decrypting said enabling key 
block included in said encrypted content ac- '5 
quired by said content acquiring means, 
through the use of said device node key stored 
in said storing means; and 
outputting means for outputting the content de- 
crypted by said decrypting means. 20 

17. An information processing method for use with an 
information processing apparatus for outputting 
contents, said information processing method com- 
prising the steps of: 2 $ 

storing a device node key corresponding to an 
extent between a leaf which is assigned to said 
information processing apparatus and which is 
subordinate to a first node on a given level of a 30 
key-managed hierarchical tree structure, and 
said first node which is assigned a content pro- 
vision category; 

acquiring an encrypted content including an en- 
abling key block for associating said first node 35 
with a root key; 

decrypting said encrypted content by decrypt- 
ing said enabling key block included in said en- 
crypted content acquired in said content acquir- 
ing step, through the use of said device node *o 
key stored in said storing step; and 
outputting the content decrypted in said de- 
crypting step. 



with a root key; 

decrypting said encrypted content by decrypt- 
ing said enabling key block included in said en- 
crypted content acquired in said content acquir- 
ing step, through the use of said device node 
key stored in said storing step; and 
outputting the content decrypted in said de- 
crypting step. 

1 9. A program executable by a computer for controlling 
an information processing apparatus for outputting 
contents, said program causing said computer to 
carry out the steps of: 

storing a device node key corresponding to an 
extent between a leaf which is assigned to said 
information processing apparatus and which is 
subordinate to a first node on a given level of a 
key-managed hierarchical tree structure, and 
said first node which is assigned a content pro- 
vision category; 

acquiring an encrypted content including an en- 
abling key block for associating said first node 
with a root key; 

decrypting said encrypted content by decrypt- 
ing said enabling key block included in said en- 
crypted content acquired in said content acquir- 
ing step, through the use of said device node 
key stored in said storing step; and 
outputting the content decrypted in said de- 
crypting step. 



18. A storage medium which stores a computer-reada- <s 
ble program for use with an information processing 
apparatus for outputting contents, the program 
comprising the steps of: 

storing a device node key corresponding to an so 
extent between a leaf which is assigned to said 
information processing apparatus and which is 
subordinate to a first node on a given level of a 
key-managed hierarchical tree structure, and 
said first node which is assigned a content pro- 55 
vision category; 

acquiring an encrypted content including an en- 
abling key block for associating said first node 
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